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

[William Lee]

I agreed that Qname type can be used, however, it's been a controversial
type to use throughout the history of XSD, because interpretation of a QName
value needs contextual information (the enclosing elements and their xmlns
declaration). 

<jsdl:JobDefinition ...>
    ...
    <jsdl:CPUArchitecture>myns:sparc</jsdl:CPUArchitecture>
    ...
</jsdl:JobDefinition>

For the parser, it needs to resolve the "myns" namespace prefix from the
enclosing elements in order to deduce whether it's in the jsdl namespace or
others.

I'm easy both ways (token / qname), although I don't think going Qname makes
the definition any richer. I just want to point out the argument from an
implementers' point of view.

William

On 23/11/04 2:06 pm, "Donal K. Fellows" <donal.k.fellows at manchester.ac.uk>
wrote:

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

--- William Lee [Software Coordinator] @  London e-Science Centre -------
A: Room 348, 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
-----------------------------------------