[jsdl-wg] Version 1.0 of the XSD Schema for JSDL

[Donal K. Fellows]

A Stephen McGough wrote:
> Attached is the XSD Schema defined at the face-to-face meeting held in 
> London on the 17-19th November 2004. This schema should be read in 
> conjunction with the JSDL draft document that came out of this meeting 
> and is available on GridForge.
> 
> As always please try out the schema and let the list know of your 
> experiences. We'd be particularly interested in those people who try to 
> describe jobs they normally use vendor DRM systems for. What extensions 
> do you require to describe your jobs and how easy is it to describe the 
> jobs.

First off, this is all absolutely great. So I'm just going to nit-pick
at what you've done. :^D

Thinking about what was said at the F2F and reading the XSD spec
carefully, I suspect that we really want to be using xsd:QName in many
places where we're using xsd:token right now (with the names we define
probably being in the same namespace as the elements, either that or a
separate namespace for such tokens.)

In particular, the following types probably need to derive from QName:
   operator, ApplicationTypeEnumeration, FileSystemTypeEnumeration,
   CreationFlagEnumeration, LimitTypeEnumeration

The types ProcessorArchitectureEnumeration and
OperatingSystemTypeEnumeration should be OK coming from xsd:token, and
their values may contain (single) spaces. In terms of correspondence of
these terms with CIM:

   P.A.E. ought to allow the defined set of string values that correspond
   to the defined CIM_Processor.Family values (*not* the numeric forms)
   but the detail in CIM is probably counter-productive for most apps.

   O.S.T.E. is the defined set of string values that correspond to the
   defined CIM_OperatingSystem.OSType values (*not* the numeric forms).

These were all taken based on the preliminary version of CIM 2.9, and
the URL to reference is http://www.dmtf.org/standards/cim/ (there are
also a lot of semi-correspondences through the rest of the resources,
but CIM tends to describe the system whereas we're describing a request,
so it is better to keep them separate.) Curiously, no other types that
we've identified can be grounded in CIM.

Also, rangeValue could derive from xsd:token and not just xsd:string so
we could pick up the normalization rules.

The various kinds of Units enumerations perhaps should derive from
NCName? Either that or we should track how the UR-WG did it, even if we
disagree with their approach.

Donal.