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@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@doc.ic.ac.uk | william@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 -----------------------------------------