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

[William Lee]

I agree with Karl's suggestion that URIs would be a better 
representation to name items in an extensible set of 'things'. Although 
QNames would be fine for things that are unlikely to be changed or 
represent in other means, such as "frequency". However OperatingSystem 
and the like are clearly extensible. Use of URI is much closer to ways 
things are named in other metadata framework, such as RDF.

If URI is used, we just have to clearly enumerate the normative list in 
the spec. rather than buried inside the XSD schema.

William

On 16 Mar 2005, at 11:16, Karl Czajkowski wrote:

> 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
>
>
--- William Lee @  London e-Science Centre, Imperial College London --
--- Software Coordinator ---
A: Room 380, Department of Computing, Imperial College London,  Huxley
Building, South Kensington campus, London SW7 2AZ, UK
E: wwhl at doc.ic.ac.uk | william at imageunion.com
W: www.lesc.ic.ac.uk | www.imageunion.com
P: +44(0)20 7594 8251
F: +44(0)20 7581 8024

--- Projects ----------------------------
GridSAM: http://www.lesc.ic.ac.uk/gridsam
Markets: http://www.lesc.ic.ac.uk/markets
ICENI:   http://www.lesc.ic.ac.uk/iceni
-----------------------------------------