[
Lists Home |
Date Index |
Thread Index
]
Time, I think for a summary. I know Roger does these well, but I will
have a go in this case since I raised the issue.
What we are trying to do is take a global XML Schema schema, i.e. one
defined for world-wide use, and tailor it for a specific locale. One
suggestion was to leave this to the authority in each locale to do,
and that is reasonable, but they still need a mechanism. Here are some
choices:
1. Alter the original schema documents
2. Use <xs:redefine> to create new documents
3. Supplement with an additional (possibly embedded) schema using an
alternative schema language
4. Use XSLT
5. Embed all the locale material in a single document and use a
pre-processor to create the locale-specifc versions
I would immediately like to rule out option 1 for change management
reasons.
I would also like to rule out option 5 and any others that involve
embedding local requirements in global documents. This could work on a
smaller scale, but here we have potentially thousands of local
variations, so it is totally impractical.
I will also take out the "possibly embedded" from option 3 for similar
reasons. I don't really want to alter the original documents.
I then think options 3 and 4 are similar - we are saying that we can
add additional constraints by supplementing the XML Schema schema with
additional constraints in another language. Whether this is
Schematron, RELAX NG, XSLT, some rules-based language or just hard
coding is a side issue. Why do we need another language? Because XML
Schema is effectively "closed" in that is forbids anything not
specifically allowed, while we need a schema that allows what is not
expressly forbidden. I don't think use of <xs:any> etc is enough to
allow us to use two XML Schema schemas in series.
So those are the choices when we have a requirement to have a base
schema with a large number of local variations - use a second "open"
schema (including use of XSLT as a schema language) or use
<xs:redefine>. Both have the benefit of not altering the global
schema.
The use of <xs:redefine> is certainly appealing - we have a single
schema against which to validate for each locale rather than having to
process two (in separate languages) in series. Change management is
reasonably simple, but possibly error prone. Change in the global
schema requires recoding of the locales, which is a shame. This is
caused by the need to replicate information that is not being changed
when applying restrictions. It could be that this can be minimized by
careful design. I suspect that my schemas are already coded to make
this reasonably easy, but some further definitions of named complex
types could help. It would be interesting to experiment. Why is this
error-prone? Well, I know that XML Spy (4.3) will not report an error
if a type changes (say by adding an element) but the derived
(restricted) type is not changed to match. I have not tried other
tools. Certainly, an automated check for this would be required. And
no - I have not yet checked the spec to see what action should be
taken, or even really thought about it yet.
Using an "open" language to apply further constraints has different
benefits. The main one is that changes in the global schema do not
require changes in the locale if they are to be adopted. I see this as
a potentially major benefit. The downside is that we have an
additional processing stage that I think will be unappealing to the
community that will have to implement the systems that use these
schemas.
My intention is to experiment a bit with the <xs:redefine> to see just
how big the derived schema documents become. Then I feel I will have a
good view of the better mechanism for this and other circumstances.
Thanks to all for the discussion.
--
Paul Spencer
|
