I think, there are various people using XML who like having XML data without any validation. I'm a strong proponent of having validation nearly always when using XML. Comparing the situation with RDBMS data, would make this clear I think (I don't mind proving things about a technology, taking cues from another technology which is hugely popular). Do we ever use data in RDBMS tables, without the schema (we don't)? The same should apply to XML, since validation is very closely defined alongside XML (DTD at least, and then XSD). If DTD or XSD is provided along with XML parsing, by the XML toolkit of choice, then why shouldn't we use validation whenever we're using XML -- as a consequence, we're working with a better design?
Interestingly, validation doesn't always happen when using XML, because it hasn't been made mandatory in the XML language (like schemas with RDBMS). People using XML, sometimes like having XML data quickly transported between components or stored locally -- and they don't use validation in the process; which is fine since it meets the needs of an application.
Sometimes, people using XML are influenced by how JSON is used. Presently, JSON doesn't has a schema language (but I came to know, that this may change in the future), and JSON is very popular & useful for certain use cases. Therefore, people try to use XML the same way -- i.e without validation.
Sunday, January 7, 2018
Sunday, December 31, 2017
Xerces bug XERCESJ-1687
I wish to share my anguish, that following Xerces bug has caused me:
https://issues.apache.org/jira/browse/XERCESJ-1687
The bug reporter is very right in his arguments. But somehow I've to say, the Xerces team cannot fix this bug right now. I've also been thinking to "resolve" this bug with a fix reason "later" (but my conscience doesn't allow that either).
I hope the situation will improve.
https://issues.apache.org/jira/browse/XERCESJ-1687
The bug reporter is very right in his arguments. But somehow I've to say, the Xerces team cannot fix this bug right now. I've also been thinking to "resolve" this bug with a fix reason "later" (but my conscience doesn't allow that either).
I hope the situation will improve.
Friday, August 25, 2017
Zoomable Android image view
By default, an ImageView is not zoomable in an Android app by a finger touch. Just found a brilliant customization of Android's ImageView, which is zoomable. It's located here: https://github.com/MikeOrtiz/TouchImageView.
To use it in the app, we just have to do TouchImageView iv = (TouchImageView) findViewById(R.id.img); (in an Activity's onCreate method for example). Of course, TouchImageView supports all the behavior of standard ImageView class.
To use it in the app, we just have to do TouchImageView iv = (TouchImageView) findViewById(R.id.img); (in an Activity's onCreate method for example). Of course, TouchImageView supports all the behavior of standard ImageView class.
Monday, August 7, 2017
Mathematical table data with XML Schema 1.1
Here's a simple example, using XML Schema 1.1 <assert> to validate elementary school mathematical tables.
XML document:
<?xml version="1.0"?>
<table id="2">
<x>2</x>
<x>4</x>
<x>6</x>
<x>8</x>
<x>10</x>
<x>12</x>
<x>14</x>
<x>16</x>
<x>18</x>
<x>20</x>
</table>
XSD 1.1 document:
<?xml version="1.0"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="table">
<xs:complexType>
<xs:sequence>
<xs:element name="x" minOccurs="10" maxOccurs="10"/>
</xs:sequence>
<xs:attribute name="id" type="xs:positiveInteger" use="required">
<xs:annotation>
<xs:documentation>Mathematical table of @id is represented.</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:assert test="x[1] = @id"/>
<xs:assert test="every $x in x[position() gt 1] satisfies $x = $x/preceding-sibling::x[1] + @id">
<xs:annotation>
<xs:documentation>An XPath 2.0 expression validating the depicted mathematical table.
</xs:documentation>
</xs:annotation>
</xs:assert>
</xs:complexType>
</xs:element>
</xs:schema>
XML document:
<?xml version="1.0"?>
<table id="2">
<x>2</x>
<x>4</x>
<x>6</x>
<x>8</x>
<x>10</x>
<x>12</x>
<x>14</x>
<x>16</x>
<x>18</x>
<x>20</x>
</table>
XSD 1.1 document:
<?xml version="1.0"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="table">
<xs:complexType>
<xs:sequence>
<xs:element name="x" minOccurs="10" maxOccurs="10"/>
</xs:sequence>
<xs:attribute name="id" type="xs:positiveInteger" use="required">
<xs:annotation>
<xs:documentation>Mathematical table of @id is represented.</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:assert test="x[1] = @id"/>
<xs:assert test="every $x in x[position() gt 1] satisfies $x = $x/preceding-sibling::x[1] + @id">
<xs:annotation>
<xs:documentation>An XPath 2.0 expression validating the depicted mathematical table.
</xs:documentation>
</xs:annotation>
</xs:assert>
</xs:complexType>
</xs:element>
</xs:schema>
Tuesday, August 1, 2017
Great write up on XML Schema 1.1
On this page, http://www.xfront.com/xml-schema-1-1/ Roger L. Costello has posted some wonderful write up on XML Schema 1.1 technology. Enthusiasts are encouraged to read that.
Roger's language is very simple, and covers almost everything from the perspective of XML Schema 1.1 user's needs.
Roger's language is very simple, and covers almost everything from the perspective of XML Schema 1.1 user's needs.
Thursday, July 13, 2017
XML Schema 1.1 inheritable attributes
I've been thinking to write 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" in the XSD 1.1 specification).
The XSD 1.1 inheritable attributes, are primarily useful when implementing XSD Type Alternatives.
Below is an XSD 1.1 example, and two corresponding valid XML instance documents. This example as a whole implements 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>
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 instance documents shown above should be validated with the XSD document provided.
Following is little explanation 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. Please notice that, how an attribute defined on element "X" makes the definition of attribute accessible to element "Y" in the schema document.
I hope that, this blog post is useful.
The XSD 1.1 inheritable attributes, are primarily useful when implementing XSD Type Alternatives.
Below is an XSD 1.1 example, and two corresponding valid XML instance documents. This example as a whole implements 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>
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 instance documents shown above should be validated with the XSD document provided.
Following is little explanation 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. Please notice that, how an attribute defined on element "X" makes the definition of attribute accessible to element "Y" in the schema document.
I hope that, this blog post is useful.
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.
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.
Subscribe to:
Posts (Atom)