[
Lists Home |
Date Index |
Thread Index
]
"Paul Spencer" <paul@alphaxml.com> writes:
<snip/>
> 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.
I didn't understand your second option, so I'll concentrate on this
one, where I also have a possible misunderstanding issue: you say "we
alter the schema document itself", I presume in reference to the
'localised' schemas for each particular election type.
Surely this isn't necessary. If the optional->required|prohibited
move is the only move involved, and locale-specific renaming isn't
required, then <redefine> will do precisely what is required.
global.xsd
<complexType name="electionReport">
<sequence>
. . .
<element ref="auditReport" minOccurs="0"/>
. . .
</sequence>
</complexType>
UK.xsd
<redefine schemaLocation="global.xsd">
. . .
<complexType name="electionReport">
<complexContent>
<restriction base="electionReport">
<sequence>
. . .
<element ref="auditReport"/>
. . .
</sequence>
</restriction>
</complexContent>
</complexType>
. . .
</redefine>
US.xsd
<redefine schemaLocation="global.xsd">
. . .
<complexType name="electionReport">
<complexContent>
<restriction base="electionReport">
<sequence>
. . .
<element ref="auditReport" maxOccurs="0"/>
. . .
</sequence>
</restriction>
</complexContent>
</complexType>
. . .
</redefine>
This is exactly what <redefine> was designed for.
Alternatively, the locale-specific schema docs can just <include> the
global one, define their own restricted types with their own names
based on the global ones, and use xsi:type in the appropriate places
in their instance documents.
There are obvious tradeoffs between these approaches, but either is
preferable in my opinion to editting by hand and maintaining multiple
versions, as you point out.
ht
--
Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
W3C Fellow 1999--2002, part-time member of W3C Team
2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
Fax: (44) 131 650-4587, e-mail: ht@cogsci.ed.ac.uk
URL: http://www.ltg.ed.ac.uk/~ht/
[mail really from me _always_ has this .sig -- mail without it is forged spam]
|
