[jsdl-wg] XSD Schema - latest

[Donal K. Fellows]

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