[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Misuse of Schematron

  • From: "Costello, Roger L." <costello@mitre.org>
  • To: "xml-dev@lists.xml.org" <xml-dev@lists.xml.org>
  • Date: Sun, 12 Apr 2015 15:19:11 +0000

Misuse of Schematron

Hi Folks,

So you've got this table which shows the data items that are applicable to each type of publication:

 

Title

Name

Author

Date

ISBN

Publisher

Volume

Lead Story

Book

 

 

 

 

 

 

 

 

Magazine

 

 

 

 

 

 

 

 

Newspaper

 

 

 

 

 

 

 

 

 

In your XML Schema you declare a complexType, Publication, containing all the data items listed along the top row. You declare each of them optional. You include a "Type" element to indicate whether the publication is a Book, Magazine, or Newspaper. Here's what you produce:

    <xs:complexType name="Publication">
       
<xs:sequence>
           
<xs:element name="Type">
               
<xs:simpleType>
                   
<xs:restriction base="xs:string">
                       
<xs:enumeration value="Book" />
                       
<xs:enumeration value="Magazine" />
                       
<xs:enumeration value="Newspaper" />
                    
</xs:restriction>
               
</xs:simpleType>
           
</xs:element>
           
<xs:element name="Title" type="xs:string" minOccurs="0" />
           
<xs:element name="Name" type="xs:string" minOccurs="0" />
           
<xs:element name="Author" type="xs:string" minOccurs="0" />
           
<xs:element name="Date" type="xs:date" minOccurs="0" />
           
<xs:element name="ISBN" type="xs:string" minOccurs="0" />
           
<xs:element name="Publisher" type="xs:string" minOccurs="0" />
            
<xs:element name="Volume" type="xs:unsignedByte" minOccurs="0" />
           
<xs:element name="Lead_Story" type="xs:string" minOccurs="0" />
       
</xs:sequence>
   
</xs:complexType>

Hmm, that's not right. If Type=Book then only a subset of the elements are applicable. Ditto for Type=Magazine and Type=Newspaper. To compensate for this incorrectness you create a Schematron schema to specify the actual allowable elements:

    <sch:pattern id="Publication">
       
        
<sch:rule context="Publication[Type='Book']">
           
<sch:assert test="Title and Author and Date and ISBN and Publisher and
                                                empty(* except (Title[1], Author[1], Date[1], ISBN[1], Publisher[1]))"
>
                A Book contains only this data: Title, Author, Date, ISBN, and Publisher
           
</sch:assert>
       
</sch:rule>
       
        
<sch:rule context="Publication[Type='Magazine']">
           
<sch:assert test="Name and Date and Publisher and Volume and
                                                empty(* except (Name[1], Date[1], Publisher[1], Volume[1]))"
>
                A Magazine contains only this data: Name, Date, Publisher, and Volume
           
</sch:assert>
       
</sch:rule>
       
        
<sch:rule context="Publication[Type='Newspaper']">
           
<sch:assert test="Name and Date and Publisher and Lead_Story and
                                                empty(* except (Name[1], Date[1], Publisher[1], Lead_Story[1]))"
>
                A Newspaper contains only this data: Name, Date, Publisher, and Lead_Story
           
</sch:assert>
       
</sch:rule>
       
    
</sch:pattern>

Let's recap: the XML Schema asserts that, for Type=Book, the Title element is optional and the Schematron schema asserts that it's required … the XML Schema asserts that the Lead_Story element is optional and the Schematron schema asserts that it's disallowed.

The XML Schema and the Schematron schema are making conflicting assertions. Surely that is a sign of poor design.

The problem boils down to this: The above table was viewed as specifying business rules: If the type is Book, then there must be Title, Author, Date, and so forth. But that's not correct. The table defines components, not business rules. That is, the table is defining the data requirements for a Book component, a Magazine component, and a Newspaper component.

The table is a definition of components,
not a definition of business rules.

Here's the right way to implement the table. Define an empty Publication complexType:

    <xs:complexType name="Publication">
       
<xs:sequence />
   
</xs:complexType>

Then define three components – Book, Magazine, Newspaper – that extend Publication:

    <xs:complexType name="Book">
       
<xs:complexContent>
           
<xs:extension base="Publication">
               
<xs:sequence>
                   
<xs:element ref="Title" />
                   
<xs:element ref="Author" />
                   
<xs:element ref="Date" />
                   
<xs:element ref="ISBN" />
                   
<xs:element ref="Publisher" />
               
</xs:sequence>
           
</xs:extension>
       
</xs:complexContent>
   
</xs:complexType>
   
    
<xs:complexType name="Magazine">
       
<xs:complexContent>
           
<xs:extension base="Publication">
               
<xs:sequence>
                   
<xs:element ref="Name" />
                   
<xs:element ref="Date" />
                   
<xs:element ref="Publisher" />
                   
<xs:element ref="Volume" />
               
</xs:sequence>
           
</xs:extension>
       
</xs:complexContent>
   
</xs:complexType>
   
    
<xs:complexType name="Newspaper">
       
<xs:complexContent>
           
<xs:extension base="Publication">
               
<xs:sequence>
                   
<xs:element ref="Name" />
                   
<xs:element ref="Date" />
                    
<xs:element ref="Publisher" />
                   
<xs:element ref="Lead_Story" />
               
</xs:sequence>
           
</xs:extension>
       
</xs:complexContent>
   
</xs:complexType>

Each component defines exactly what elements belong to it, so there is no need for Schematron.

Schematron is an awesome tool. But use it for the purpose it was designed for: to express business rules.

Comments welcome.

/Roger



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.