OAGi uses XML Schema to define OAGIS, which is a horizontally focused Canonical Business Language used to enable integration both within an enterprise and across Supply Chains. Through working with vertical industry groups, OAGIS is extended to meet the specific needs of these vertical industries.

XML Schema's typing system is certainly an improvement over DTDs. OAGIS uses this to validate not only the simple types but also define our own complex types to create structures needed to communicate business data. These types are then bound to elements so as to be used within instance documents.

OAGi makes use of complex type derivation by extension in order to inherit base definitions forward to meet the specific needs of given components. This limits the number of times the same definitions must be created. We use this approach not only within OAGIS itself but also by the vertical industries to create what OAGi calls an Overlay, where a vertical industry may add their industry specific content, without modifying OAGIS, itself.

OAGi also makes use of substitution groups. Substitution groups are used to enable the Overlay extended elements to be plugged-in in place of the existing OAGIS element.

Simple type union is the only way to create a type that provides a recommended set of code lists while realizing that there maybe a need to allow values outside of that code list, where the code list is implemented as an enumeration.

OAGIS uses the model groups sequence and choice.

While we use substitution groups within in OAGIS, they force us into design choices that we would not have made otherwise. Currently substitution groups can only be created for global elements. If it were possible to create substitution groups for local elements as well, we would not be forced into these design choices.

Complex type derivation by restriction simply does not work. The way it is currently designed does nothing more than make a copy of the base type and allow the schema designer to further restrict the new copy. If something then changes in the base type those changes are unknown to the new derivation. Add to this the fact that derivation by restriction is not allowed across namespaces. Because of this we do NOT use complex type derivation by restriction. If instead complex type derivation by restriction were more like complex type derivation by extension, in that the changes to the base type were allowed to pass through unless filtered to do otherwise. Also, if this complex type derivation by restriction were permitted to be used across namespaces.

Schema location attribute is not consistently defined. In the case of :

• An xsi:schemaLocation intended to be used for an instance the recommendation indicates that the location is a hint from the author as to where the xsd definition can be found, additionally the attribute is optiona.
• An include the attribute is required and this time it must reference an xsd document.
• An import the attribute is optional, again if present it is a hint as to where the find the given xsd document.

Since the schemaLocation attribute is to either point to the definition of the instance or to a definition that further defines the current schema file, we recommend that the schemaLocation be definitive. Instead of a hint, it should be the location in which the xsd file is located.

Redefine - while OAGi does not use redefine, it allows schema authors to redefine different types and element. Redefines do not work across namespaces, so only the schema author can redefine. Our experience says that things defined should remain consistently defined within their scope. While local elements may be defined deferently depending upon their scope. If redefines were allowed across namespaces it would be possible for a schema to be further defined by users other that the author.

We avoid using the model group all, because of the implied sequence of these models when inherited from base types.

The interoperability problems we have experienced are largely a result of people not reading the recommendation, not understanding the recommendation, or simply not implementing parts of the recommendation.

An example of this is the simple type union most tools today do not support the simple type union but the recommendation defines it.

N/A

Not really a single feature… but more the perceived complexity of schema for the lay person.

We have created a Practical Guide to XML Schema document that outlines the features of XML Schema that should be supported. It also indicates the features that may be difficult to implement.

This has helped our customer member organization to know what to ask their vendors specifically what they support.

It has also helped our vendor members to know what features of XML Schema that they must support.

No. We have tested against several standard parsers, XML IDE's and several of our members EAI tools.