We need to point as many of these out as possible to whoever has the pen (Andreas?)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.
(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?
Just looked at the doc (fresh download) in 5.1.2.5 we have:
<JobDescription>
<JobIdentification ...
/>?
<User id="xsd:uri” ...
/>?
<Application
id="xsd:uri" ... />?
<Resource id="xsd:uri”
... />*
<DataStaging
id="xsd:uri” ... />*
<jsdl:any/>*
</JobDescription>
Droped this down to optional. I think I was thinking about Annotation elements.(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).
OK so for the sake of consistency We'll make this a range. Writers of consumers can then worry about how to deal with ranges.(8) FileSystem.DiskSpace You give xsd:positiveInteger as type, while the spec statesjsdl: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.
Agreed, we should just keep it for the overall document. How about the Profile sections? These aren't overwritten in the same way and could be potentially used between documents. I'd see an argument to do these as xsd:ID.(17) Ids used in the schema XML Schema offers two types to use for ids and to referencethem 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 andare a perfect match for our schema, wherever we use the Id attribute for elements, I suppose.Were 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.
Think we're down to 4 now. Out of these 4 1 and 17 still need some consideration while 4 and 8 are potentially resolved.After all, this leaves 7 quirky things, if I did not overlook others. We're closing in on the finish line!
-- ------------------------------------------------------------------------ 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 ------------------------------------------------------------------------