This was my intention to rise some issues based on our experience of developing XML schemas for our applications, implementing them in Java and testing their performance. Otherwise we will be simply using JSDL in our application in whatever form we will have it :-) a) Regarding issues 1, 4, 7, 8 about moving from elements to attributes you can read about XML document processing difference here http://msdn.microsoft.com/library/en-us/dnpag/html/scalenetchapt09.asp http://support.microsoft.com/default.aspx?scid=kb;en-us;815124 where two basic XML processing operations are compared XML parsing and XPath building. You would not object that these two will be used widely in Grids and WS. Also to add that programing for attributes will be simpler. b) about referring to CIM and DMTF This is an old story about CIM vs XML Schema. Just to think what community stands behind each of this technologies. Also XML Schema is a key technology in XML Web Services chain and their are many tools to support data (de)serialisation/(de)marchalling automatically in XWS applications. IMHO, all this bunch of technologies vouch for some schema design preferences. If you want to use CIM enumeration, you still have two options whether to use it in elements or attributes, and see a) c) about issue 5 on "typing" This is exactly from my experience with XML Spy and with managing multiple namespaces. Some additional arguments can be that complexTypes can be easily used outside of particular schema and transformed to other datatypes - what we actually would like to have in our applications when referencing some datatypes defined in JSDL. About this here: http://www.xml.com/pub/a/2002/11/20/schemas.html?page=2 d) about issue 6 on anyAttribute against managed attributes semantics/namespaces/values
No. This conflicts with other standards, future plans, etc.
This is exactly our concern with coordinating and managing attribute naming in EGEE project with security applications. IMHO, defining some limits with attribute naming and provided some kind of naming tree in the form of URI will provide more order and coordination with future extensions. At least we are going to do this with user credentials, attributes and policy definitions. e) issue 9 is mostly about Security consideration in your JSDL definition. IMHO, it should mandatory part of specification. This issue is also from our security solutions development for EGEE and other Grid based projects. Job submission must be enough secured not only at transport message level but also at document level. Security is normally linked to the requesting subject/principal. And if go further, the Requestor will want that Job submission security/authenticity is bound to the JobDescription itself and not to sending application (i.e., MLS). You can ensure Job authenticity (in relation to requestor) and integrity by (1) linking between Subject name and its confirmation in a form of secure credentials, and (2) signing the JobDescription. So, my additional comments below.
9) consider changing the User element definition and consider the following issues:
- How ExecutionUserID relates to UserCredential * is nameId the same?
Not necessarily.
* how they are connected semantically and cryptographically?
Out of scope :^) In fact, there is no need for them to have any specific connection at all, though presumably anything handed a document containing these things which doesn't believe them would throw it out. Those elements do not secure the document in any way.
* who assigns user groups and they are confirmed
Confirmation is completely out of scope. We don't specify at all what you actually have to do with the document; we just specify what the elements mean. OK, it's a narrow difference, but it means that we are not developing services at all. (That's someone else's problem, and
Consider this as mandatory (?) Security consideration as explained above. they
are the poor saps who have to figure out how to secure such a thing.)
You may not bore about applying security mechanism but you need to provide facility for this in your schema. This my comment as a security developer concern. Regards, Yuri Donal K. Fellows wrote:
I apologize if some of these answers seem a touch short-tempered, but it's late and I'm having trouble sleeping despite being very tired. :^/
Yuri Demchenko wrote:
1) consider moving some of child elements to attribute
Rationale: this actually should improve readability and programming
I don't see it as important. IME this is one of those debates that rages in the general XML community, producing much heat and little light. I say keep it the same on the grounds that it's less changes for us to do. :^) Also, other elements (e.g. some of the DataStaging sub-elements) have their primary content as real content (and have to because it is structured) and so we ought to remain consistent there and always.
2) consider moving attributes definition/enumeration to the end of the schema - for better readability
Or a different actual document included. ;^) Or don't bother.
3) consider having all elements' name capitalised and attributes preferably starting from small letter
I think everything's supposed to be that way and deviations are probably just minor spec and/or schema bugs.
4) consider moving enumerated elements like LimitTypeEnumeration or OSenumeration to attributes
No. Those are primary content of their containing elements.
5) consider defining element in a form of data "typing"
Example:
<xs:element name="Credentials" type="iodef-xws:CredentialsType"/> <xs:complexType name="CredentialsType"> <xs:sequence> <xs:element ref="iodef-xws:CredentialData" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="iodef-xws:CredentialConfirmation" minOccurs="0"/> <xs:element ref="iodef-xws:CredentialStorage" minOccurs="0"/> </xs:sequence> <xs:attribute ref="iodef:restriction" default="default"/> <xs:attribute ref="iodef-xws:credstatus" use="required"/> </xs:complexType>
Rationale: It will make software generation and further document validation more straitforward and compatible with existing tools.
This is based on our experience.
XMLSpy is happy enough. :^) I'd suggest not expending major effort on this at this stage; it could be done for 1.1 (i.e. it'd just be an alternate presentation of the same datatype system) and it's probably more work than we want to take on now when we're trying to close the first fully public version and get it out the door.
6) consider where you can avoid using <xsd:anyAttribute namespace="##other" processContents="lax"/>
Practice shows that attribute should have clear name and definition. However, its semantics/meaning can be typically defined by type="anyURI" and consequently you can use externally maintained registry specific for your application and namespace.
Example (typical for SAML and XACML):
<NameIdentifier Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" NameQualifier="cnl:subject:customer">WHO740@users.collaboratory.nl</NameIdentifier>
No. This conflicts with other standards, future plans, etc.
7) consider making OS more flexible and more light
Rationale: actually OS specs in most cases is enumerated, so no need to have it as an element, however you need more information like vendor, name, version, patch.
Possible format - element "OperatingSystem" may be empty
<xs:element name="OperatingSystem"> <xs:complexType> <xsd:sequence> <xsd:element name="Description" type="jsdl:description" minOccurs="0"/> </xsd:sequence> <xs:attribute name="vendor" type="xs:string"/> <xs:attribute name="name" type="xs:string"/> <xs:attribute name="version" type="xs:string"/> <xs:attribute name="patch" type="xs:string"/> </xs:complexType> </xs:element>
No. We adopted an external standard (an approach we have tried to follow whereever possible as a matter of policy). If you want to complain, talk to the DMTF about CIM being over-rigid and heavyweight. ;^)
8) the same approach can be applied to the Limit element and some other
No, because that hurts from an interoperability viewpoint.
9) consider changing the User element definition and consider the following issues:
- How ExecutionUserID relates to UserCredential * is nameId the same?
Not necessarily.
* how they are connected semantically and cryptographically?
Out of scope :^) In fact, there is no need for them to have any specific connection at all, though presumably anything handed a document containing these things which doesn't believe them would throw it out. Those elements do not secure the document in any way.
* who assigns user groups and they are confirmed
Confirmation is completely out of scope. We don't specify at all what you actually have to do with the document; we just specify what the elements mean. OK, it's a narrow difference, but it means that we are not developing services at all. (That's someone else's problem, and they are the poor saps who have to figure out how to secure such a thing.)
All assignment of groups etc. is done by the creator of the document. Presumably they'd encapsulate the document in something like a signed envelope or something, but that's not our problem since JSDL is also quite usable in scopes that have nothing to do with the Grid or SOAP (e.g. it could be used as an internal format by a batch scheduler, or it could be transferred across a kerberized ssh connection, or ...)
Possible solution - three components User/Principal nameID, Credentials (that cryptographically confirm nameID and/or contain own ConfirmationData) and Attributes where you can put all non-ID data
<xs:element name="Principal" type="jsdl:PrincipalType"/> <xs:complexType name="PrincipalType"> <xs:sequence> <xs:element ref="jsdl:NameIdentifier"minOccurs="0"/> <xs:element ref="jsdl:Credentials" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="jsdl:Attributes" minOccurs="0"/> </xs:sequence> <xs:attribute ref="jsdl:principalcat" default="other"/> </xs:complexType>
Looks like an extension to me. :^)
Donal.