Thursday, July 13, 2017

XML Schema 1.1: inheritable attributes in action

I felt like writing a small and complete example, clarifying the role of XML Schema 1.1 inheritable attributes (please see inheritable = boolean within the definition "XML Representation Summary: attribute Element Information Item").

The XSD 1.1 inheritable attributes, are primarily useful while implementing Type Alternatives.

Below is a specific XSD 1.1 example, and two corresponding valid XML documents. These as a whole implement inheritable attributes, and few other areas of XSD 1.1.

XSD document:

<?xml version="1.0"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
 
   <xs:element name="X">
      <xs:complexType>
         <xs:sequence>
            <xs:element name="Y">
               <xs:alternative test="@y = 'A'">
                  <xs:complexType>
                     <xs:sequence>
                        <xs:element name="A">
                           <xs:complexType>
                              <xs:simpleContent>
                                 <xs:extension base="xs:string">
                                    <xs:attribute name="attr" type="xs:integer"/>
                                 </xs:extension>
                              </xs:simpleContent>                              
                           </xs:complexType>
                        </xs:element>
                     </xs:sequence>
                  </xs:complexType>
               </xs:alternative>
               <xs:alternative test="@y = 'B'">
         <xs:complexType>
                     <xs:sequence>
                        <xs:element name="B">
                           <xs:complexType>
                              <xs:simpleContent>
                                 <xs:extension base="xs:string">
                                    <xs:attribute name="attr" type="xs:integer"/>
                                 </xs:extension>
                              </xs:simpleContent>                              
                           </xs:complexType>
                        </xs:element>
                     </xs:sequence>
                  </xs:complexType>              
               </xs:alternative>
            </xs:element>
         </xs:sequence>
         <xs:attribute name="y" inheritable="true">
            <xs:simpleType>
               <xs:restriction base="xs:string">
                 <xs:enumeration value="A"/>
                 <xs:enumeration value="B"/>
               </xs:restriction>
            </xs:simpleType>
         </xs:attribute>
      </xs:complexType>
   </xs:element>
 
</xs:schema>

(the most interesting parts are shown italicized)

XML document 1:

<?xml version="1.0"?>
<X y="A">
  <Y>
    <A attr="1">hello</A>
  </Y>
</X>

XML document 2:

<?xml version="1.0"?>
<X y="B">
  <Y>
    <B attr="1">hello</B>
  </Y>
</X>

The XML documents shown (1 & 2) should be validated with the XSD document provided.

I'll provide a little explanation here, with-respect-to the semantics of this example:
An inheritable attribute "y" is defined on element "X". The XSD type of element "Y" is chosen at runtime (i.e at validation time), depending on the value of this attribute. Notice how, the attribute defined on element "X" makes its definition accessible to element "Y" in the schema document.

If you're a novice to XML Schema 1.1, I'd suggest reading some areas of the XML Schema 1.1 language more deeply.

I do hope, that this post is useful to some practitioners in this field.

Tuesday, June 13, 2017

XSLT 3.0 reaches W3C Recommendation status

Not long ago, XSLT 3.0 has reached the W3C Recommendation status. Below is the link to the XSLT 3.0 spec:

https://www.w3.org/TR/2017/REC-xslt-30-20170608/

XSLT 3.0 is a very advanced and useful language, as compared to XSLT 2.0. One of the main features (among others) introduced in XSLT 3.0, is that the XSLT transformation can be done in streaming mode.

Thursday, June 1, 2017

XPath 2.0 atomization in XML Schema 1.1 validation

XPath 2.0 atomization as a concept, as applicable to XML Schema 1.1 validation is worth looking at. I would like to ponder on this in this post, with a brief example.

Consider the following brief XML Schema 1.1 validation example.

XSD 1.1 document:

<?xml version="1.0"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
 
   <xs:element name="X">
      <xs:complexType>
         <xs:sequence>
            <xs:element name="a" type="xs:integer"/>
            <xs:element name="b" type="xs:integer"/>
         </xs:sequence>
         <xs:assert test="a gt b"/>
      </xs:complexType>
   </xs:element>
 
</xs:schema>

XML document that is fed to the XML Schema 1.1 validator, when validating with the above XSD document:

<?xml version="1.0"?>
<X>
  <a>4</a>
  <b>7</b>
</X>

This XML document fails validation, because "a" is less than "b". Now what is XPath 2.0 atomization, as for in this example that I want to talk about?

Since the XML document has been validated with the mentioned XSD, while building the XPath tree to apply <assert>, the nodes of the tree are annotated (or decorated) with the XSD types as mentioned in the XSD document. Therefore, the <assert> XPath 2.0 expression "a gt b", comes with runtime availability of the corresponding XSD types on <assert> tree nodes for "a" and "b". In XPath 2.0 terms, the <assert> tree nodes for "a" and "b" have been atomized. The Schema aware XPath 2.0 in action, is same in <assert> as in the generic Schema aware XPath 2.0 processor.

The XSD 1.1 processor that I've used for this example is located at https://svn.apache.org/repos/asf/xerces/java/branches/xml-schema-1.1-dev/.

Wednesday, May 17, 2017

Turing Award 2016

Its nice to see, Sir Tim Berners-Lee as a recipient of A.M. Turing Award. More details are available on http://awards.acm.org/about/2016-turing.

Sunday, December 18, 2016

XML Schema 1.1 type alternative patterns


Please note that, XML Schema 1.1 type alternatives allows selection of an XML Schema type depending on something related to attributes.

I think use of XML Schema 1.1 type alternatives fall into the following 2 broad patterns:

1) When an attribute is mandatory

The following XML Schema document illustrates this use:

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">

   <xs:element name="X">
      <xs:alternative test="@a = 'val1'" type="XType1"/>
      <xs:alternative test="@a = 'val2'" type="XType2"/>
      <xs:alternative type="XType3"/>
   </xs:element>
  
   <xs:complexType name="XType1">
      <xs:sequence>
        <xs:element name="A" type="xs:integer"/>
        <xs:element name="B" type="xs:integer"/>
      </xs:sequence>
      <xs:attribute name="a" type="xs:string" use="required"/>
   </xs:complexType>
  
   <xs:complexType name="XType2">
      <xs:sequence>
         <xs:element name="C" type="xs:integer"/>
         <xs:element name="D" type="xs:integer"/>
      </xs:sequence>
      <xs:attribute name="a" type="xs:string" use="required"/>
   </xs:complexType>
  
   <xs:complexType name="XType3">
      <xs:sequence>
         <xs:element name="P" type="xs:integer"/>
         <xs:element name="Q" type="xs:integer"/>
      </xs:sequence>
      <xs:attribute name="a" type="xs:string" use="required"/>
   </xs:complexType>
 
</xs:schema>

Following are some of XML instance documents, which are valid according to the above schema document.

<X a="val1">
  <A>1</A>
  <B>2</B>
</X>

i.e when attribute's value is "val1", a specific complex type is assigned to X.

<X a="val2">
  <C>1</C>
  <D>2</D>
</X>

i.e when attribute's value is "val2", a specific complex type is assigned to X.

and

<X a="something else">
  <P>1</P>
  <Q>2</Q>
</X>

i.e when attribute's value is anything other than "val1" or "val2", a specific complex type is assigned to X.  

2) When an attribute is optional

The following XML Schema document illustrates this use:

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">

   <xs:element name="X">
      <xs:alternative test="@a" type="XType1"/>
      <xs:alternative test="not(@a)" type="XType2"/>
   </xs:element>
  
   <xs:complexType name="XType1">
      <xs:sequence>
        <xs:element name="A" type="xs:integer"/>
        <xs:element name="B" type="xs:integer"/>
      </xs:sequence>
      <xs:attribute name="a" type="xs:string" use="optional"/>
   </xs:complexType>
  
   <xs:complexType name="XType2">
      <xs:sequence>
         <xs:element name="C" type="xs:integer"/>
         <xs:element name="D" type="xs:integer"/>
      </xs:sequence>
      <xs:attribute name="a" type="xs:string" use="optional"/>
   </xs:complexType>
 
</xs:schema>

Following are some of XML instance documents, which are valid according to the above schema document.

<X a="something1">
  <A>1</A>
  <B>2</B>
</X>

i.e when an attribute is present, a specific complex type is assigned to X.

and

<X>
  <C>1</C>
  <D>2</D>
</X>

i.e when an attribute is absent, a specific complex type is assigned to X.

I hope that this post is useful.

Sunday, November 13, 2016

XML Schema : <assert> helps us process wild-cards and attributes

Please let me illustrate my point with the following XML Schema (1.1) example:

XML Schema document:
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">

   <xs:element name="X">
     <xs:complexType>
        <xs:sequence>
           <xs:any processContents="skip" minOccurs="3" maxOccurs="3"/>
        </xs:sequence>
        <xs:attribute name="y1" type="xs:string"/>
        <xs:attribute name="y2" type="xs:string"/>
        <xs:attribute name="y3" type="xs:string"/>
        <xs:assert test="deep-equal(for $el in * return name($el), for $at in @* return name($at))"/>
     </xs:complexType>
   </xs:element>
 
</xs:schema>

This schema document says following:
1) A wild-card requires 3 element nodes.
2) There are 3 attribute nodes, of same cardinality as the elements.
3) The <assert> says that, name of elements validated by wild-cards must be same as the names of attributes.

Here's a valid XML document for the above schema document:
<?xml version="1.0" encoding="UTF-8"?>
<X y1="A" y2="B" y3="C">
  <y1>A</y1>
  <y2>B</y2>
  <y3>C</y3>
</X>

Reference to XPath 2.0 language (for <assert> path expressions) : https://www.w3.org/TR/xpath20/.

I hope this example is useful.

Friday, October 28, 2016

XML Schema 1.1 : assertion refines enumeration

In this post, I'll try to explain how the XML Schema 1.1 <assertion> facet refines the XML Schema <enumeration> facet in useful ways, and also helps us build a useful domain vocabulary written in the XML Schema language.

Consider the following XML Schema 1.1 document:

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">

   <xs:element name="day" type="Day"/>
  
   <xs:element name="workday" type="WorkDay"/>
  
   <xs:element name="holiday" type="Holiday"/>
  
   <xs:simpleType name="WorkDay">
      <xs:restriction base="Day">
         <xs:assertion test="$value != 'saturday' and $value != 'sunday'"/>
      </xs:restriction>
   </xs:simpleType>
  
   <xs:simpleType name="Holiday">
     <xs:restriction base="Day">
        <xs:assertion test="$value = 'saturday' or $value = 'sunday'"/>
     </xs:restriction>
   </xs:simpleType> 
  
   <xs:simpleType name="Day">
      <xs:restriction base="xs:string">
         <xs:enumeration value="monday"/>
         <xs:enumeration value="tuesday"/>
         <xs:enumeration value="wednesday"/>
         <xs:enumeration value="thursday"/>
         <xs:enumeration value="friday"/>
         <xs:enumeration value="saturday"/>
         <xs:enumeration value="sunday"/>
      </xs:restriction>
   </xs:simpleType>
 
</xs:schema>

This is a very simple XSD document, and the XML documents validated by this XSD document will also be very simple.

The following is one invalid document for the given schema,
<holiday>wednesday</holiday>

To my opinion, this example has illustrated how the <assertion> facet refines the <enumeration> facet during simple type derivation, and also helps us clearly build a fine domain vocabulary. The types "WorkDay" and "Holiday" are verbally linked to the type "Day" in the XML Schema document as in this example.