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.
8) 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.