[jsdl-wg] Re: Some comments on the Schema & first draft of XSD v.1.0

[A Stephen McGough]

Michel,

I'll try to respond to your points below.

General note: This has brought a large number of inconsistencies in the 
document to light. Michel you seem to have used the psudo-schema in 
order to write your version while I used the other parts of the 
document. These discrepencies need to be resolved. For now I've stuck 
with the document rather than the psudo-schema unless the psudo-schema 
makes much more sense.

Michel Drescher wrote:

>Dear Stephen (and fellow mailing list members),
>
>I couldn't help but mess arount with JSDL as well - and here is my result. Use whatever you can use. :-)
>Some things I spotted in your version (and mine), who are also of general interest:
>  
>
Thanks for doing this - I knew there would be errors in this - was 
getting schema blind and couldn't spot them!

>(1) JobDescription
>You give xsd:anyType as type for the any element, the spec says xsd:any##other?
>  
>
Erm, In the copy of the Schema I have here (the one from the end of 
Friday) it has a jsdl:any in JobDescription. That seems to be what I 
have in the schema.

>(2) Profile
>The id attribute is xsd:anyURI, didn't we agree to use xsd:NCName for all IDs?
>  
>
Sorry missed that one - now corrected.

>(3) Application
>The doc states that Application has NO id, your schema defines one?
>  
>
That's probably a reminant from an old version. Removed.

>(4) Application
>Your schema defines AplicationDescription to be unbounded, the spec states it's optional?
>  
>
I had this as unbounded as all other Description elements in the schema 
are unbounded. Happy to change it to optional. Though we should 
beconsistent over the document.

>(5) HostSpecificEnvironment
>Residual from old spec?
>  
>
Yep - removed - cheers.

>(6) EnvironmentVariables
>Residual from old spec?
>  
>
Yep - same for this one.

>(7) Resource
>The spec defines xsd:any##other as extension mechanism, you use xsd:anyType?
>  
>
The schema has jsdl:any which is the same as the doc. This forces people 
to add an ID tag to their element.

>(8) FileSystem.DiskSpace
>You give xsd:positiveInteger as type, while the spec states jsdl:rangeValue? (I'd prefer the latter)
>  
>
Spec discrepency! psudo-schema and doc don't match
The spec seems to have xsd:positiveInteger as the type. However, as we 
have an operator on this element does it make sense to change it to a 
range? I can understand "-10Gb" or "20Gb-" but do the following make 
sense? "10Gb, 20Gb, 80Gb"?

>(9) Network
>Residual from old spec? (Resource element defines its own NetworkBandwidth element...)
>  
>
Yep - outdated and removed.

>(10) DataStaging
>It misses the id attribute?
>  
>
Added.

>(11) DataStaging.FileSystemID
>The spec defines this to be required, you define it as optional?
>  
>
Spec discrepency! psudo-schema and doc don't match
Ah, there's an inconsistency in the document here. The Multiplicity is 
marked as 0-1 while the psudo-schema has it manditory. Presumably we 
used the respective forms. I'd say this item should be optional. We need 
to make a decision on this and match the two up.

>(12) frequencyUnits, bandwidthUnits, operator, storageUnits, limitValue
>I'd propose to use xsd:NMTOKEN as type, as this does not allow whitespaces (I'd prefer that).
>  
>
Agreed, and changed. I've used "noUnits" rather than "integer" - think 
it's slightly more descriptive.

>(13) limitUnits
>It's a nice solution (mine was way more lame). However, it's missing time elements (for CPUTime, wallTime, etc) and simple integers (for openDescriptors etc).
>  
>
I've added timeUnits in  - we should add this to the doc. Also added 
xsd:nonNegativeInteger too.

>However, we have a "definition hole" in here. Consider the following XML snippet:
><jsdl:JobDescription>
>    <jsdl:Limits>
>        <jsdl:Limit jsdl:name="CPUTime" jsdl:units="hour">33</jsdl:Limit>
>        <jsdl:Limit jsdl:name="virtualMemory" jsdl:units="GB">16</jsdl:Limit>
>        <jsdl:Limit jsdl:name="openDescriptors" jsdl:units="integer">159</jsdl:Limit>
>        <jsdl:Limit jsdl:name="fileSize" jsdl:units="day">666</jsdl:Limit>
>    </jsdl:Limits>
></jsdl:JobDescription>
>While this validates against the schema (with my version of the limitUnits type), the "fileSize" limit definition has a major flaw...
>We either keep the elegant and short schema definition as it is now for Limits and Limit and specify in the spec document, that "the consuming system MUST interpret a Limit element's units and name attributes according to meaningful values. Otherwise the JSDL document MUST be rejected."
>Or, we bloat up the schema with distinct Limit subelements. You pick the poison...
>  
>
Yes this is a big problem with XML schema's. However, this problem goes 
across the board. Anywhere where we specify a string (or arbitary token) 
we can put in any form of gibberish. For example the following fragment 
is valid XML (and in some case may also be a valid job)
<jsdl:Executable>The Cat Sat on the mat</jsdl:Executable>
I don't think XSD can tie down all cases. So it's reasonable to allow 
the consumer to throw your example (and or mine).
Hopefully a later schema definition language than XSD will allow these 
things to be checked.

>(14) rangeValue
>this regular expression looks ugly ;-) Can we use '\d' to describe decimal letters? Makes the expression easier to read...
>  
>
Nathalie has sent me a revised version of this definition, which 
actually works. I'll put \d into it and add it after doing this email.

>(15) ApplicationTypeEnumeration, ProcessorArchitecture(Type)Enumeration, FileSystemTypeEnumeration, OperatingSystemTypeEnumeration, CreationFlagEnumeration, LimitTypeEnumeration
>Almost all of them have an empty jsdl:token restriction too many, that have no function but bloat the schema. Additionally, I'd propose to use xsd:NMTOKEN as type, which does not allow whitespaces. This collides with the current enumerations (especially OperatingSystemTypeEnumeration), but offers a stricter definition. xsd:token is "too relaxed" in my opinion. Additionally, please align the naming, your ProcessorArchitectureEnumeration is missing a "Type" in between (sorry for being pedantic here ;-)
>  
>
Ah, is this the <xsd:union memberTypes="xsd:token"> right at the start 
of each of them? If so this is needed to allow people to add to the 
list. If you don't then the list that we send out can't be extended - or 
at least that's what the XSD document I read claimed. Anyone have a more 
definative answer to that one?

Changed them to xsd:NMTOKEN though

>(16) jsdl:any
>My solution is completely different to yours - I have no clue why. Can you enlighten me, please? :-)
>  
>
Ah, I've used the xsd:anyType rather than the xsd:any element. The 
advantage of using the xsd:anyType is that other attributes than the 
forced id tag can be put on the element by whoever extends things. Other 
than that they do pretty much the same.

>(17) Ids used in the schema
>XML Schema offers two types to use for ids and to reference them in a XML document:
>xsd:ID     - http://books.xmlschemata.org/relaxng/ch17-77096.html
>xsd:IDREF  - http://books.xmlschemata.org/relaxng/ch17-77101.html
>and even
>xsd:IDREFS - http://books.xmlschemata.org/relaxng/ch17-77106.html
>I think these are exactly the types we were looking for and are a perfect match for our schema, wherever we use the Id attribute for elements, I suppose.
>  
>
Where exactly are you proposing these are used? Just for the whole 
document or at each unbounded element? I see you have xsd:ID for the 
document. If this is the only place then fine. I've updated the other 
schema to match.

>Again, thank you guys for a remarkable productive F2F meeting at Imperial College!
>
>Cheers,
>Michel
>
Thanks for all the comments, please keep them comming in!

steve..

-- 
------------------------------------------------------------------------
Dr A. Stephen McGough
------------------------------------------------------------------------
Research Associate,   Imperial College London,  Department of Computing,
180 Queen's Gate,    London SW7 2BZ, UK
tel: +44 (0)207-594-8310                        fax: +44 (0)207-581-8024
------------------------------------------------------------------------
Assistant Warden,  West Wing,  Beit Hall,  Imperial College,
Prince Consort Road, London, SW7 2BB            tel: +44 (0)207-594-9910
------------------------------------------------------------------------