[jsdl-wg] XSD Schema - latest - schema design issues

[Karl Czajkowski]

I would like to add a few comments in case it can make the next
session more lively today. :-)

I agree with Donal that some of the attribute versus element concerns
are mostly aesthetics or religion, rather than quantifiable
improvements that help most or all tooling environments or
applications.

I also have some concerns about the large enumerations in the current
schema, not because I think transcribing an existing concept space is
bad, but because our experience in Globus is that enumeration types
are not very amenable to use in extensible schema, or in external
specifications where we might wish to exploit JSDL.  I had stated in a
previous session that I thought we should replace the enumerations of
platforms, units, etc. w/ QNames, but I discussed it with some of our
own XML gurus and they suggested that we should instead simply
enumerate a set of normative URIs, one for each "concept" such as
"MHz" or "SunOS".  For example, we could simply allocate a
sub-hierarchy under the JSDL namespace URI, e.g.:

  http://www.ggf.org/namespaces/2005/03/units/MHz
  ...
  http://www.ggf.org/namespaces/2005/03/operatingSystem/Linux
  ...
  http://www.ggf.org/namespaces/2005/03/comparison/equalTo

which do not correspond to any XSD construct.  This is preferrable to
QNames for one important reason: having QNames as values in XML causes
problems for a class of "untyped" XML rewriters such as are present in
WS-Security canonicalization.  These generic tools are unable to
safely rewrite namespace prefix bindings and prefix references
(something they unfortunately have to do to be conformant) without
knowing the content model (schema) to distinguish QName value fields
from values that just happen to look like QNames.  This means the
tools need to either fail on such documents, or fall back to a slower
"runtime type processing" mode.

If we do this, the places that currently have one of the JSDL
enumeration types would instead have xsd:anyURI.  I think this is an
acceptable "loss" in typing precision because it allows other future
documents to import JSDL concepts like units, platforms, etc. simply
by using our normative concept URIs in the context of their own
documents.


karl

-- 
Karl Czajkowski
karlcz at univa.com