Home arrow XML arrow Page 2 - Schematron Patterns and Validation
XML

Schematron Patterns and Validation


In the last article, we grouped assertions into rules. As you know, each rule has its own context that it acts upon. So, grouping assertions into a rule provides a way to organize assertions that apply to the same elements. In this article, we'll start by explaining patterns, which takes organization to a new level.

Author Info:
By: Peyton McCullough
Rating: 4 stars4 stars4 stars4 stars4 stars / 7
January 14, 2009
TABLE OF CONTENTS:
  1. · Schematron Patterns and Validation
  2. · Abstract Patterns
  3. · Validation
  4. · Conclusion

print this article
SEARCH DEVARTICLES

Schematron Patterns and Validation - Abstract Patterns
(Page 2 of 4 )

Abstract patterns also exist in Schematron. They are similar to abstract rules in that they must be extended in some way by other patterns, but they are more complex and powerful, and they solve a different problem. Sometimes, two XML structures convey the same information, but they are structured differently. Abstract patterns allow a way to operate on both structures in the same way.

Say, for example, that we're representing an e-mail and a Windows Live instant message in XML. The markup for the two might look something like this:


<email>
  <header>
    <
to>johndoe@nothing.developershed.com</to>
    <
from>joesmith@nothing.developershed.com</from>
  </
header>
  <
body>
    Hello. How are you?
  </body>
</
email>
<
live_message>
  <
to>johndoe@nothing.developershed.com</to>
  <
from>joesmith@nothing.developershed.com</from>
  <
message>
    Hello. How are you?
  </message>
</
live_message>


The same information is conveyed in both structures: a sender, a recipient, and a message. The same constraints, then, could apply to both structures. For example, we could make sure that the elements representing the information do indeed exist. However, the elements representing these fields are at different paths in each structure and may have different names. Based on this, it might seem that we'd have to create two patterns that are essentially duplicates of each other just to accommodate the different paths and element names.

However, abstract patterns provide a much easier and shorter way to do this. We can create an abstract pattern that deals with everything in an abstract matter. Using an abstract pattern, we can, for example, create the markup that checks for a sender without knowing exactly how the sender is represented. Then, another pattern could extend this and pass the exact location of the sender element as a parameter. The abstract parameter would reference the values of these parameters in order to set constraints.

Let's see how all of this would look. If we wanted to verify that each message has a sender, a recipient, and a message, then we're checking for the presence of three elements. This requires one rule and three assertions. The rule context expression and the test expression simply point to the location of the relevant elements. Since we don't know the exact paths, though, we can use parameter references. Let's create the abstract pattern for all of this, using parameter references for what we don't know. To create an abstract pattern, the abstract attribute of the pattern element needs to be set to “true,” and the pattern needs to be given a unique identifier using the id attribute. Here's what the abstract pattern looks like:


<pattern id="message_structure" abstract="true">
  <
rule context="$message">
    <
assert test="$sender">
      A message has a sender.
    </assert>
    <
assert test="$recipient">
      A message has a recipient.
    </assert>
    <
assert test="$body">
      A message has a body.
    </assert>
  </
rule>
</
pattern>


As you can see, the abstract pattern looks just like a normal pattern, except the rule context expression and the test expressions are just references to the parameters. Other patterns can pass the necessary values as parameters. They simply need to have is-a attributes that point to the abstract pattern. Here are the two patterns to test the structure of an e-mail and a Windows Live message:


<pattern id="email_structure" is-a="message_structure">
  <
param name="message" value="email" />
  <
param name="sender" value="header/from" />
  <
param name="recipient" value="header/to" />
  <
param name="body" value="body" />
</
pattern>
<
pattern id="live_message_structure" is-a="message_structure">
  <
param name="message" value="live_message" />
  <
param name="sender" value="from" />
  <
param name="recipient" value="to" />
  <param name="body" value="message" />
</
pattern>


Now, the XML structure representing an e-mail and the XML structure representing a Windows Live message will both be checked for a sender, a recipient, and a body, even though these three pieces of information are represented differently.


blog comments powered by Disqus
XML ARTICLES

- Open XML Finally Supported by MS Office
- XML Features Added to Two Systems
- Using Regions with XSL Formatting Objects
- Using XSL Formatting Objects
- More Schematron Features
- Schematron Patterns and Validation
- Using Schematron
- Datatypes and More in RELAX NG
- Providing Options in RELAX NG
- An Introduction to RELAX NG
- Path, Predicates, and XQuery
- Using Predicates with XQuery
- Navigating Input Documents Using Paths
- XML Basics
- Introduction to XPath

Watch our Tech Videos 
Dev Articles Forums 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us 
Weekly Newsletter
 
Developer Updates  
Free Website Content 
Contact Us 
Site Map 
Privacy Policy 
Support 

Developer Shed Affiliates

 




© 2003-2017 by Developer Shed. All rights reserved. DS Cluster - Follow our Sitemap
Popular Web Development Topics
All Web Development Tutorials