Working with a Metaschema
by Will Provost
|
Pages: 1, 2
Strategies
Once the standard metaschemas are in hand, we can see several techniques for leveraging the WXS metamodel:
We could extend or restrict the metaschema,
creating our own types where necessary, for instance a
mySchema or myLocalSimpleType.
This is a non-starter, though, because it flunks the first
of our criteria: models which observe this derived
metaschema would not function as ordinary WXS schemas
because our derived types would be unknown to generic WXS
tools.
We could define metamodel information in our own
namespace, and allow candidate schemas to use both the
WXS namespace and our own. This is simple enough and is
explicitly allowed under WXS by the openAttrs
base type, which allows schema components to include
attributes from other namespaces. This technique works
well enough for extending the metamodel, but it doesn't
address requirements for restriction.
We could rewrite the WXS metaschema to suit our purposes. That is, we could simply edit XMLSchema.xsd to change component definitions. This feels a bit icky, and it certainly poses the risk of breaking compatibility with WXS proper. It is a valid approach, however, so long as one exercises great care in making changes.
WXS provides a means of incrementally changing existing
schemas, in order to create new versions. This is the
redefine component, and it turns out
to be a potent means of leveraging the WXS metamodel
itself. Only certain components can be redefined --
remember the redefinable type from the overview diagram. Still, this is a
preferable approach to creating modified metaschema
documents for maintenance as well as aesthetic
reasons.
Pattern-based validation is always an option,
and it's an especially strong one here. In implementing
various rules, we'll face the usual limitations of WXS in
expressing document-scope constraints; with
redefine as our best option for reuse, we're
additionally hobbled. Constraints expressed in XPath and
asserted via XSLT or Schematron can establish rules that
none of the above techniques can manage.
Examples
We'll now look at a series of simple examples that illustrate most of the techniques described above.
Using redefine
Let's say we're building a component that creates a graphical form for entry of application data. We want to use WXS as our type model to define the shape of this data, but the business requirements have been bounded so that the following WXS constructs are unnecessary:
- Derived complex types
- Nested hierarchies of child elements (we only want a two-level hierarchy of parent-child)
- Conjunctions (
all) in content models (we only want sequences and choices)
Each of these constraints can be expressed with a
separate redefinition of the WXS metamodel. Therefore we
build our own metaschema whose target is the standard WXS
namespace. It includes a single redefine
element:
<?xml version='1.0' encoding='UTF-8'?>
<xs:schema
targetNamespace="http://www.w3.org/2001/XMLSchema"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:redefine schemaLocation="XMLSchema.xsd">
</xs:redefine>
</xs:schema>
A redefine can hold any number of
redefinitions, so we'll add each of the three as children
of the empty element shown above. First, we'll nix
complex-type derivation. Here's another piece of the WXS
metamodel, showing how type extension is implemented:
Our target is the complexTypeModel: we
redefine this to exclude complexContent and
simpleContent as modeling options:
<xs:group name="complexTypeModel">
<xs:choice>
<xs:sequence>
<xs:group ref="xs:typeDefParticle" minOccurs="0"/>
<xs:group ref="xs:attrDecls"/>
</xs:sequence>
</xs:choice>
</xs:group>
Removal of all content models is similarly
straightforward. The target now is the
typeDefParticle, which as the previous
diagram shows is a focal point of the content modeling
system.
Our redefinition simply fails to list all as a member of the group:
<xs:group name="typeDefParticle">
<xs:choice>
<xs:element name="group" type="xs:groupRef"/>
<xs:element ref="xs:choice"/>
<xs:element ref="xs:sequence"/>
</xs:choice>
</xs:group>
Finally we attack the localElement
component, forbidding deep hierarchies of complex-type
elements by insisting that a local element have only
simple type. A redefine of a complex type
has the odd appearance of a type extending itself:
<xs:complexType name="localElement">
<xs:complexContent>
<xs:restriction base="xs:localElement">
<xs:sequence>
<xs:element ref="xs:annotation" minOccurs="0"/>
<xs:choice minOccurs="0">
<xs:element name="simpleType" type="xs:localSimpleType"/>
</xs:choice>
<xs:group ref="xs:identityConstraint" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>(Note that the distinction in the standard metamodel between
topLevelElement and localElement
is critical here: without it we'd potentially be
prohibiting complex-type elements, period, which would
make for some pretty trivial document models.)
The completed metaschema is GUIBuilder.xsd.
See also a valid candidate schema Valid.xsd, as
well as three that each flunk one of the constraints: DerivedType.xsd,
UsesAConjunction.xsd,
and NestedTypes.xsd.
Note that all of the candidate schemas are valid
under normal WXS — just change the
schemaLocation from
"GUIBuilder.xsd" to "XMLSchema.xsd" to
prove it.
Namespace Extension
Perhaps our GUI builder can handle choice and union
types, although this obviously adds complexity. Two or
more parallel interface panels must be presented to the
user, which is a solvable problem. What to say about
these panels, though? If the application is asked to
allow entry of either a city and state or a ZIP code,
for example, how can the application indicate to the
user which panel means what? The most intuitive
approach would be for the candidate schema to name each
of the possible choices in some descriptive way. WXS
doesn't allow all possible children of
choice to be named, though, and, even if it
did, component names are not generally meant for
end-user consumption.
Here an attribute from a separate namespace is the natural choice for extending the content model. A very simple schema is developed for the new "named choices" namespace, and the candidate schema simply references this along with the normal WXS metaschema.
Pattern-Based Validation
Let's say a given processor can't work with missing
attribute values. The requirement is set that any
attribute in the model must either be required or must
provide a default value. This is not so easy to redefine
using the attribute component type. We've
stumbled across a general weakness of WXS: content model
constraints based on instance values cannot be
implemented.
In XPath, by contrast, it is dead simple to express this rule, and using XSLT it is just as easy to enforce it. The validating transform below can be applied to the candidate schema (see documents ExplicitAttributes.xsl and MissingDefault.xsd).
<?xml version="1.0" encoding="UTF-8" ?>
<xsl:transform version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xsl:output method="text" />
<xsl:strip-space elements="*" />
<xsl:template match="text ()" />
<xsl:template match="//xs:attribute
[(@use='optional' or not (@use)) and not (@default)]">
<xsl:text>ERROR: Must provide a default value for optional attribute </xsl:text>
<xsl:value-of select="@name" />
<xsl:text>.</xsl:text>
</xsl:template>
</xsl:transform>
Conclusion
|
More from XML Schema Clinic |
This system isn't perfect. There are many ways in which I'd like to leverage the WXS metamodel that are either closed to me or just too complicated to be worth the trouble. This isn't a shortcoming in WXS, as I see it; if the type model were as pliable as I'd like it to be, it just wouldn't be W3C XML Schema and wouldn't have the tremendous descriptive power and precision that I also want.
Where they are feasible, redefinitions of schema components offer an elegant way to tailor the WXS model to the needs of an application. XPath/XSLT validation can provide another option, but it's important to see past logistics and remember that the WXS metamodel is as stiff as it is for a reason. If you find yourself demanding features in your application's candidate schema that make them malformed under WXS proper, or changing so many things that the metamodel is unrecognizable, you should probably be building your metamodel from scratch or working from a different starting point.
Share your thoughts on this article with other readers by posting in our forum.
(* You must be a member of XML.com to use this feature.)
Comment on this Article
| Titles Only | Titles Only | Newest First |
- XMLSchema.xsd and GUIBuilder.xsd are not valid (Xerces)
2004-07-22 02:09:32 OndrejRohlik [Reply]
Hello!
I get the following several pairs of the following error messages (for different complexTypes):
SystemID: D:\AtETH\FMT\MetaXsdExperiments\XMLSchema.xsd
Location: 695:29
Description: E rcase-Recurse.2: There is not a complete functional mapping between the particles.
URL: http://www.w3.org/TR/xmlschema-1/#rcase-Recurse
and
SystemID: D:\AtETH\FMT\MetaXsdExperiments\XMLSchema.xsd
Location: 695:29
Description: E derivation-ok-restriction.5.4.2: Error for type 'all'. The particle of the type is not a valid restriction of the particle of the base.
URL: http://www.w3.org/TR/xmlschema-1/#derivation-ok-restriction
using Oxygen 4.1 xml editor that uses Xerces implementation 2.6.2 with "schema-full-checking" option on.
What a pitty
- XMLSchema.xsd and GUIBuilder.xsd are not valid (Xerces)
2004-08-23 06:45:05 OndrejRohlik [Reply]
The answer/hint is here:
http://www.oxygenxml.com/forum/ftopic510.html
- XMLSchema.xsd and GUIBuilder.xsd are not valid (Xerces)
- xPath rules with Schematron
2002-11-14 04:09:19 Charlie McCay [Reply]
In the article the option of using XSLT to express rules based constraints on structure of schemas, with xPaths to compliment the constraints expressed in the metaschema. Schematron [1] provides a simpler strucure in which to express such xPath constraints. The schematron rules can be embedded into the metaschema, allowing both approaches to be combined.
[1] http://www.ascc.net/xml/resource/schematron/schematron.html
[2] [3] http://www.topologi.com/public/Schtrn_XSD/Paper.html
