Version 1.0 of the XSD Schema for JSDL
All, Attached is the XSD Schema defined at the face-to-face meeting held in London on the 17-19th November 2004. This schema should be read in conjunction with the JSDL draft document that came out of this meeting and is available on GridForge. As always please try out the schema and let the list know of your experiences. We'd be particularly interested in those people who try to describe jobs they normally use vendor DRM systems for. What extensions do you require to describe your jobs and how easy is it to describe the jobs. Many thanks, 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 ------------------------------------------------------------------------
A Stephen McGough wrote:
Attached is the XSD Schema defined at the face-to-face meeting held in London on the 17-19th November 2004. This schema should be read in conjunction with the JSDL draft document that came out of this meeting and is available on GridForge.
As always please try out the schema and let the list know of your experiences. We'd be particularly interested in those people who try to describe jobs they normally use vendor DRM systems for. What extensions do you require to describe your jobs and how easy is it to describe the jobs.
First off, this is all absolutely great. So I'm just going to nit-pick at what you've done. :^D Thinking about what was said at the F2F and reading the XSD spec carefully, I suspect that we really want to be using xsd:QName in many places where we're using xsd:token right now (with the names we define probably being in the same namespace as the elements, either that or a separate namespace for such tokens.) In particular, the following types probably need to derive from QName: operator, ApplicationTypeEnumeration, FileSystemTypeEnumeration, CreationFlagEnumeration, LimitTypeEnumeration The types ProcessorArchitectureEnumeration and OperatingSystemTypeEnumeration should be OK coming from xsd:token, and their values may contain (single) spaces. In terms of correspondence of these terms with CIM: P.A.E. ought to allow the defined set of string values that correspond to the defined CIM_Processor.Family values (*not* the numeric forms) but the detail in CIM is probably counter-productive for most apps. O.S.T.E. is the defined set of string values that correspond to the defined CIM_OperatingSystem.OSType values (*not* the numeric forms). These were all taken based on the preliminary version of CIM 2.9, and the URL to reference is http://www.dmtf.org/standards/cim/ (there are also a lot of semi-correspondences through the rest of the resources, but CIM tends to describe the system whereas we're describing a request, so it is better to keep them separate.) Curiously, no other types that we've identified can be grounded in CIM. Also, rangeValue could derive from xsd:token and not just xsd:string so we could pick up the normalization rules. The various kinds of Units enumerations perhaps should derive from NCName? Either that or we should track how the UR-WG did it, even if we disagree with their approach. Donal.
I agreed that Qname type can be used, however, it's been a controversial type to use throughout the history of XSD, because interpretation of a QName value needs contextual information (the enclosing elements and their xmlns declaration). <jsdl:JobDefinition ...> ... <jsdl:CPUArchitecture>myns:sparc</jsdl:CPUArchitecture> ... </jsdl:JobDefinition> For the parser, it needs to resolve the "myns" namespace prefix from the enclosing elements in order to deduce whether it's in the jsdl namespace or others. I'm easy both ways (token / qname), although I don't think going Qname makes the definition any richer. I just want to point out the argument from an implementers' point of view. William On 23/11/04 2:06 pm, "Donal K. Fellows" <donal.k.fellows@manchester.ac.uk> wrote:
A Stephen McGough wrote:
Attached is the XSD Schema defined at the face-to-face meeting held in London on the 17-19th November 2004. This schema should be read in conjunction with the JSDL draft document that came out of this meeting and is available on GridForge.
As always please try out the schema and let the list know of your experiences. We'd be particularly interested in those people who try to describe jobs they normally use vendor DRM systems for. What extensions do you require to describe your jobs and how easy is it to describe the jobs.
First off, this is all absolutely great. So I'm just going to nit-pick at what you've done. :^D
Thinking about what was said at the F2F and reading the XSD spec carefully, I suspect that we really want to be using xsd:QName in many places where we're using xsd:token right now (with the names we define probably being in the same namespace as the elements, either that or a separate namespace for such tokens.)
In particular, the following types probably need to derive from QName: operator, ApplicationTypeEnumeration, FileSystemTypeEnumeration, CreationFlagEnumeration, LimitTypeEnumeration
The types ProcessorArchitectureEnumeration and OperatingSystemTypeEnumeration should be OK coming from xsd:token, and their values may contain (single) spaces. In terms of correspondence of these terms with CIM:
P.A.E. ought to allow the defined set of string values that correspond to the defined CIM_Processor.Family values (*not* the numeric forms) but the detail in CIM is probably counter-productive for most apps.
O.S.T.E. is the defined set of string values that correspond to the defined CIM_OperatingSystem.OSType values (*not* the numeric forms).
These were all taken based on the preliminary version of CIM 2.9, and the URL to reference is http://www.dmtf.org/standards/cim/ (there are also a lot of semi-correspondences through the rest of the resources, but CIM tends to describe the system whereas we're describing a request, so it is better to keep them separate.) Curiously, no other types that we've identified can be grounded in CIM.
Also, rangeValue could derive from xsd:token and not just xsd:string so we could pick up the normalization rules.
The various kinds of Units enumerations perhaps should derive from NCName? Either that or we should track how the UR-WG did it, even if we disagree with their approach.
Donal.
--- William Lee [Software Coordinator] @ London e-Science Centre ------- A: Room 348, Department of Computing, Imperial College London, Huxley Building, South Kensington campus, London SW7 2AZ, UK E: wwhl@doc.ic.ac.uk | william@imageunion.com W: www.lesc.ic.ac.uk | www.imageunion.com P: +44(0)20 7594 8251 F: +44(0)20 7581 8024 --- Projects ---------------------------- GridSAM: http://www.lesc.ic.ac.uk/gridsam Markets: http://www.lesc.ic.ac.uk/markets ICENI: http://www.lesc.ic.ac.uk/iceni -----------------------------------------
William Lee wrote:
I agreed that Qname type can be used, however, it's been a controversial type to use throughout the history of XSD, because interpretation of a QName value needs contextual information (the enclosing elements and their xmlns declaration).
<jsdl:JobDefinition ...> ... <jsdl:CPUArchitecture>myns:sparc</jsdl:CPUArchitecture> ... </jsdl:JobDefinition>
For the parser, it needs to resolve the "myns" namespace prefix from the enclosing elements in order to deduce whether it's in the jsdl namespace or others.
That's why I wanted it. :^) The aim is to make those extensible enumerations where people can add their own elements but must do so in a way that won't tread on where we might wish to put our toes in future. The other sensible way of doing this is the informal technique used in specifications like CIM, where you just have a common prefix to all the values that you define. But if you're doing that, you might as well formalize it in terms of common XML rules. In terms of parsing, I think both SAX and DOM have support for making this sort of processing easy...? Donal.
OK, so I think we have 3 votes for QName and 1 fence sitter. Any other votes on this issue? Otherwise I think we should go for QName. steve.. Donal K. Fellows wrote:
William Lee wrote:
I agreed that Qname type can be used, however, it's been a controversial type to use throughout the history of XSD, because interpretation of a QName value needs contextual information (the enclosing elements and their xmlns declaration). <jsdl:JobDefinition ...> ... <jsdl:CPUArchitecture>myns:sparc</jsdl:CPUArchitecture> ... </jsdl:JobDefinition>
For the parser, it needs to resolve the "myns" namespace prefix from the enclosing elements in order to deduce whether it's in the jsdl namespace or others.
That's why I wanted it. :^) The aim is to make those extensible enumerations where people can add their own elements but must do so in a way that won't tread on where we might wish to put our toes in future. The other sensible way of doing this is the informal technique used in specifications like CIM, where you just have a common prefix to all the values that you define. But if you're doing that, you might as well formalize it in terms of common XML rules.
In terms of parsing, I think both SAX and DOM have support for making this sort of processing easy...?
Donal.
-- ------------------------------------------------------------------------ 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 ------------------------------------------------------------------------
Donal, Donal K. Fellows wrote:
A Stephen McGough wrote:
Attached is the XSD Schema defined at the face-to-face meeting held in London on the 17-19th November 2004. This schema should be read in conjunction with the JSDL draft document that came out of this meeting and is available on GridForge.
As always please try out the schema and let the list know of your experiences. We'd be particularly interested in those people who try to describe jobs they normally use vendor DRM systems for. What extensions do you require to describe your jobs and how easy is it to describe the jobs.
First off, this is all absolutely great. So I'm just going to nit-pick at what you've done. :^D
Nit-picking is what will make the schema much better.
Thinking about what was said at the F2F and reading the XSD spec carefully, I suspect that we really want to be using xsd:QName in many places where we're using xsd:token right now (with the names we define probably being in the same namespace as the elements, either that or a separate namespace for such tokens.)
What is the difference between xsd:QName and xsd:NMTOKEN? We've changed things over to xsd:NMTOKEN. It's easy to change to xsd:QName but I think we need to know why.
In particular, the following types probably need to derive from QName: operator, ApplicationTypeEnumeration, FileSystemTypeEnumeration, CreationFlagEnumeration, LimitTypeEnumeration
The types ProcessorArchitectureEnumeration and OperatingSystemTypeEnumeration should be OK coming from xsd:token, and their values may contain (single) spaces. In terms of correspondence of these terms with CIM:
P.A.E. ought to allow the defined set of string values that correspond to the defined CIM_Processor.Family values (*not* the numeric forms) but the detail in CIM is probably counter-productive for most apps.
We have them in now - so no more work (for me anyway). If we've missed any could people send the ones missed to the list. To make my life easy could you send the items needed to be added and not references to documents!
O.S.T.E. is the defined set of string values that correspond to the defined CIM_OperatingSystem.OSType values (*not* the numeric forms).
Ditto.
These were all taken based on the preliminary version of CIM 2.9, and the URL to reference is http://www.dmtf.org/standards/cim/ (there are also a lot of semi-correspondences through the rest of the resources, but CIM tends to describe the system whereas we're describing a request, so it is better to keep them separate.) Curiously, no other types that we've identified can be grounded in CIM.
Also, rangeValue could derive from xsd:token and not just xsd:string so we could pick up the normalization rules.
Hmm, but then people couldn't use spaces - is this going to cause people problems? I tend to write lists "2, 5, 6". Could easily ditch the spaces thoug. Also can you have commas in xsd:tokens? Thoughts please folks.
The various kinds of Units enumerations perhaps should derive from NCName? Either that or we should track how the UR-WG did it, even if we disagree with their approach.
They are now derived from xsd:NMToken.
Donal.
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 ------------------------------------------------------------------------
A Stephen McGough wrote:
What is the difference between xsd:QName and xsd:NMTOKEN? We've changed things over to xsd:NMTOKEN. It's easy to change to xsd:QName but I think we need to know why.
QName is syntactically a subset of NMTOKEN, and semantically subject to the same XML namespace rules as the elements and attributes of the document.
We have them in now - so no more work (for me anyway). If we've missed any could people send the ones missed to the list. To make my life easy could you send the items needed to be added and not references to documents!
I'm not sure that it's a very useful distinction though. In terms of what is likely to be useful, it's probably better to stick to the general instruction set classes that we've got. The problem is really that there is a partial order on the potential values for PAE but we don't really have the time to fix that (and nor is it a closed set). Yuck.
O.S.T.E. is the defined set of string values that correspond to the defined CIM_OperatingSystem.OSType values (*not* the numeric forms).
Ditto.
That's what I sent to Darren at the meeting. :^) OTOH, this is probably another case where my comments just above apply; e.g. for many apps, Win32 is just Win32 and the distinction between variants is irrelevant, but the JSDL consumer is a very specific type of OS (well, unless it is some kind of higher-level brokering/scheduling thing of course.)
Also, rangeValue could derive from xsd:token and not just xsd:string so we could pick up the normalization rules.
Hmm, but then people couldn't use spaces - is this going to cause people problems? I tend to write lists "2, 5, 6". Could easily ditch the spaces thoug. Also can you have commas in xsd:tokens? Thoughts please folks.
According to <URL:http://www.w3.org/TR/xmlschema-2/#token> commas are fine in token and non-standard whitespace is collapsed, so that allows the RE for ranges to become: RE: (\d+( ?- ?\d*)?|- ?\d+)( ?, ?(\d+( ?- ?\d*)?|- ?\d+))* ^^^^^^^^^^^^^^ ^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Expl: D or D- or D-D or -D or a comma-sep list of them (Yes, the \d is allowed in XSD; I looked it up specifically. <URL:http://www.w3.org/TR/xmlschema-2/#dt-regex> The XSD rules for REs in Appendix F are among the clearest RE syntax descriptions I've seen.) Donal.
Also, rangeValue could derive from xsd:token and not just xsd:string so we could pick up the normalization rules.
Hmm, but then people couldn't use spaces - is this going to cause people problems? I tend to write lists "2, 5, 6". Could easily ditch the spaces thoug. Also can you have commas in xsd:tokens? Thoughts please folks.
According to <URL:http://www.w3.org/TR/xmlschema-2/#token> commas are fine in token and non-standard whitespace is collapsed, so that allows the RE for ranges to become: RE: (\d+( ?- ?\d*)?|- ?\d+)( ?, ?(\d+( ?- ?\d*)?|- ?\d+))* ^^^^^^^^^^^^^^ ^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Expl: D or D- or D-D or -D or a comma-sep list of them
(Yes, the \d is allowed in XSD; I looked it up specifically. <URL:http://www.w3.org/TR/xmlschema-2/#dt-regex> The XSD rules for REs in Appendix F are among the clearest RE syntax descriptions I've seen.)
I've put this version in for now - as it seems the most complete. However, if I'm correct the following is a valid string "34-45 55-66" Am I correct? Is there any way to force people to put a comma between these? 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 ------------------------------------------------------------------------
A Stephen McGough wrote:
I've put this version in for now - as it seems the most complete. However, if I'm correct the following is a valid string "34-45 55-66"
Am I correct? Is there any way to force people to put a comma between these?
Actually, the RE-in-XSD spec also states (in a Note in the appendix) that REs in pattern facets are implicitly anchored at both ends. If you add those anchors in explicitly when testing in some other programming language (e.g. Perl) you'll see that your example is illegal. So I think my RE really is correct. :^) I did have a quick panic when you said there might be a problem with it though; it's complex enough that I couldn't be 100% sure just by inspection. :^/ Donal.
participants (3)
-
A Stephen McGough -
Donal K. Fellows -
William Lee