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

[Yuri Demchenko]

William Lee wrote:
> 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.
> 
Please, consider also another form of URI - non-URL type (e.g., like 
used by OASIS in SAML/XACML specifications)

http://www.ggf.org/namespaces/2005/03/comparison/equalTo

can be also

urn:ggf:names:JSDL:0.9:operation:function:equel-to

BTW, about functions and operations you can actually import XPath and 
XMath enumerated types.

REgards,

Yuri

> 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
> -----------------------------------------
>