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