[
Lists Home |
Date Index |
Thread Index
]
There are two reasons for needing to go beyond XML Schema on a project
that is using XML Schema as its base constraint syntax. The first is
where XML Schema cannot express the constraints required, for example,
a section of a message that is required if the value of a previous
element is "yes", but not if it is "no". Languages such as Schematron
go some way to address this and can be used either embedded in an XML
Schema schema or as free-standing documents. I will shortly be making
recommendations in this area to the UK Govt, and would welcome a
discussion here at some point.
The other situation, and the one that is a more immediate concern, is
the situation where we need to localise a general purpose schema. A
good example, since this is an OASIS-hosted group, is the Election
Markup Language (EML) on which I have been working. This is an
international collaboration, so most elements are optional, although
they might be required in a particular situation. For example, some
audit information is required in a UK parliamentary election but
forbidden in a US gubernatorial or presidential election. It is
optional in the schema, but mandatory for the UK and forbidden in the
USA. This requirement for profiling schemas is common, but not one I
have seen addressed in open discussion. Here are two ways of
approaching it:
Write new, more restrictive, schemas for each regime such that a
document that validates to the local schemas will validate to the
global schema (but not necessarily vice versa). This has the advantage
that only a single schema processor is required, and it will be an XML
Schema processor - something that Governments are generally happy
with, while they will be less happy with Schematron or RELAX NG
processors. It is also easier to read and understand, since a single
schema describes each message. The disadvantage is that we alter the
schema document itself, giving us a configuration management headache.
Even using derivation, there will be a lot of work developing and
checking any new version of the local variant when a new global
version is released.
or
Use an open (open in terms of allowing any content that is not
expressly forbidden) schema language to supplement the closed XML
Schema schema. Each document will then be validated to the XML Schema
schema, then passed on to the second schema processor for the local
variations. The advantage is that we do not modify the globally agreed
schema. This eases configuration management and conformance checking
and means that international systems providers only work with a
specific set of schema documents for the additional local constraints,
making their job easier. The disadvantage is that we need to operate
two schema processors in series, which adds an additional technology
and an additional processing overhead. Some of the applications I work
on are very high volume, so this can be an issue.
I suspect that the former is the short-term pragmatic solution, whilst
the latter is the better strategic answer if the technology (in terms
of common tools to develop and view two schema languages
simultaneously etc) is put in place. How about a tool that provides
the graphical editing environment of XML Spy whilst allowing the
developer to switch schema language for specific sets of constraints.
i.e. I could import an EML schema written in XML Schema, then work on
the graphical representation, generating a separate Schematron file
whilst leaving the original schema document intact.
I throw the discussion open to the floor.
Paul Spencer
XML Adviser to the Office of the e-Envoy
|
