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

Tue Nov 23 11:48:39 CST 2004

Guys,

here's my spam again:

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

Yes, indeed, I used the pseudo-schema. Although Dave kept track of it through the meeting, I didn't have it available when I started writing my schema version (since that was yesterday evening at home... *g*). Hence I compiled my own pseudo-schema based on the snippets given in the 
spec document posted on http://forge.gridforum.org on last Friday (thanks, Andreas!). This prep-step was quite enlightning since it really brightly demonstrated where contradictions within the document are/were (didn't keep track of these) and that the pseudo-schema truly builds up from modules. I started with the pseudo-schema on top level in pathetic notepad.exe, and replaced rough-defined elements (i.e. <User .../>) with the more detailed or completed versions given at their respective definition as I walked the document from top to bottom.

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

I know how that feels :-)

Below, I only refer to things that you did not already changed so it gives a nice "to do" list.

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

I downloaded my copy yesterday evening - maybe Andreas already changed the document since Friday?

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

Funny enough, I reckognised in my pseudo-schema all description elements as optional. But we definitely need to be consistent in dhe spec document AND the schema. However, I incline to have all descriptions optional (and not unbounded).

> >(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"?

I definitely second to have a range here. I think even the given list may make sense - if the application is written to support this (who does this?!?). Anyway, if we allow for a rangeValue here, the spec must give more detail on how a consuming system MAY react on funny values.

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

In ch 5.6.3.1 the definition clearly marks this as optional: "If the FileSystemID is specified then the FileName is relative to the specified FileSystem declaration referenced by the id. In this case there MUST also be a FileSystem Element with the same id. Otherwise the FileName is relative to the working job directory as specified by WorkingDirectory element."

So I think the pseudo-schema is wrong at this point. 

> >(13) limitUnits
[Quote reformatted due to MS Outlook comb quoting... argh!]
> [...]
> 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.

Yes I know. I just wanted to stress that point - and to give Andreas some more work with the spec document, to add this kind of interpretation. ;-)

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

Exactly, it is. I didn't think of the extensibility, though. I read the respective paragraphs in the spec document (like, 5.5.13.5, "This token can be extended as additional types are identified.") the way that the JSDL WG emends that list as there is a need for more, and publish a new version of the document.

Any other comments on that?

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

I thought to use them as a replacement for xsd:NCName where it is used as a defining identifier, i.e. in the DataStaging element.
What I just realised is that we then cannot re-use the elements of JobDescriptionSection to be also a sub-element of Profile, because then the id of type xsd:ID of, say, a DataStaging element in a Profile section MUST be different from a DataStaging element in the JobDescriptionSection element even if I wanted to supersede it. This violates the specification, unless you XSD gurus find a way to use/allow/force xsd:IDREF when the according element is a sub-element of a Profile element.

After all, this leaves 7 quirky things, if I did not overlook others. We're closing in on the finish line!

Cheers,
Michel