Waleed K. Abdulla
waleed_abdulla@xrules.org
My experience with XML Schema involves working with XML business documents in a vertical industry using schemas defined by organizations such as STAR (Standards of Technology for Automotive Retail), MIC (Motorcycle Industry Council), OAGI, and UBL. I use these schemas for validation, and as a formal method of documenting, the layout and structure XML BODs (Business Object Documents). Most of these use-cases involve having to conform to schemas that are used by several trading partners in a specific industry, and having to compromise between the needs and wishes of different organizations.
I also use XML Schema in WSDL files to describe the layout of Web Services messages exchanged between trading partners.
I’m also interested in XML Schema as part of my work on XRules, an XML rules language (http://www.xrules.org), which can be embedded in XML Schema documents to express rules that are outside the scope of XSD.
It’s common when working with XML Schemas defined by vertical industry standards organizations to have situations where two trading partners want to communicate XML documents that use values outside of the enumerated lists defined by the standard schema. XML Schema provides a method to redefine enumerations, but it’s very limited and mostly unusable for many practical situations. This forces the trading partners to have to update the standard schema, which is a practice that is not encouraged by the standards organizations, and requires the changes to be re-done for every new release of the standard schema.
A great addition to Schema 1.1 is to enhance the “redefine” concept, or replace it, to make it easier to expand (or restrict) enumerations by attaching additional schema files without having to modify the original schema. And, it’ll be wonderful if the redefinition can be restricted to a specific context rather than being always a global redefinition. That’s needed because it’s common to need to expand an enumeration in, say, a purchase order, but not in an invoice; although both use the same common enumeration element.
It would be great if XML Schema 1.1 relaxes the limitation in XML Schema 1.0 to having only one target namespace per schema. This limitation forces the XML Schema designer to use more schema files than desired, and contributes to the increased complexity of maintaining schema repositories.
One of the examples I came across that show the unfavorable effects of this limitation was the decision of STAR to change the namespace of certain elements in the STAR documents from the OAGI namespace to the STAR namespace, and in the process break backward compatibility, to reduce the pain associated with having to maintain separate schema files for the different namespace. This is a good example of how the complexity of XML Schema is affecting the design of business documents and encouraging users to make compromises that might not be the best architecturally.
This limitation becomes more visible when using more namespaces in one document, which is becoming more common especially with the increased popularity of core components that try to standardize the XML blocks that are used to describe common data components such as addresses, personal details, payment methods… etc.
When validating an XML document against the XML Schema I usually get human readable error messages generated by the schema processor. Although this is good enough during the development phase when I’m building and testing the application, these error messages are not very helpful at run time to provide good error messages to the application user.
A great additional feature to XML Schema 1.1 is to standardize syntax and error codes that are machine-readable so that my application can read them to determine the type of error and what nodes are contributing to it, take appropriate action, and provide that information to the user in an easy to understand language.
Adding annotations to XML Schema could be simplified by removing the mandatory two levels of element hierarchy. For example, in XML Schema 1.0, to add a comment to an element, I need to add two levels of elements before I can insert my comments.
<xsd:element name="internationalPrice">
<xsd:annotation>
<xsd:documentation xml:lang="en">
element declared with anonymous type
</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
…
</xsd:complexType>
</xsd:element>
This could be simplified by using the <xsd:documentation> element directly without
the <xsd:annotation> wrapper.
<xsd:element name="internationalPrice">
<xsd:documentation xml:lang="en">
element declared with anonymous type
</xsd:documentation>
<xsd:complexType>
…
</xsd:complexType>
</xsd:element>
Or, allow inserting Dublin Core elements directly in the schema to allow more flexible ways to document schema components.
And the same applies to the <appinfo> element. An alternative, used by Relax NG, is
to allow inserting application specific elements directly into the schema without the
<xsd:annotation><xsd:affinfo>…</xsd:appinfo></xsd:annotation>
wrapper. Having the application specific elements use a different namespace than that of
XML Schema is a good way to distinguish them from schema elements and have the
schema processor ignore them.
About the Author
Waleed K. Abdulla, M.Sc. Computer Engineering
Senior software developer and architect interested in Web services and rules languages.
Involved in two vertical standards organizations, and an editor of the STAR Web services
specifications used in the automotive and motorcycle industries. And, the author of the
XRules XML language for XML rules.
Email: waleed_abdulla@xrules.org