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