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: (1) JobDescription You give xsd:anyType as type for the any element, the spec says xsd:any##other? (2) Profile The id attribute is xsd:anyURI, didn't we agree to use xsd:NCName for all IDs? (3) Application The doc states that Application has NO id, your schema defines one? (4) Application Your schema defines AplicationDescription to be unbounded, the spec states it's optional? (5) HostSpecificEnvironment Residual from old spec? (6) EnvironmentVariables Residual from old spec? (7) Resource The spec defines xsd:any##other as extension mechanism, you use xsd:anyType? (8) FileSystem.DiskSpace You give xsd:positiveInteger as type, while the spec states jsdl:rangeValue? (I'd prefer the latter) (9) Network Residual from old spec? (Resource element defines its own NetworkBandwidth element...) (10) DataStaging It misses the id attribute? (11) DataStaging.FileSystemID The spec defines this to be required, you define it as optional? (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). (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). 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... (14) rangeValue this regular expression looks ugly ;-) Can we use '\d' to describe decimal letters? Makes the expression easier to read... (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 ;-) (16) jsdl:any My solution is completely different to yours - I have no clue why. Can you enlighten me, please? :-) (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. Again, thank you guys for a remarkable productive F2F meeting at Imperial College! Cheers, Michel