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

[A Stephen McGough]

Ok, the onslaught again!

I'm going to cut back tightly on this to remove those issues that are 
now dead.

>>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.
>  
>
We need to point as many of these out as possible to whoever has the pen 
(Andreas?)

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

>>>(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).
>  
>
Droped this down to optional. I think I was thinking about Annotation 
elements.

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

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

>After all, this leaves 7 quirky things, if I did not overlook others. We're closing in on the finish line!
>  
>
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.

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/jsdl-wg/attachments/20041124/c60122bf/attachment.html