[jsdl-wg] XSD Schema - latest - schema design issues

[Yuri Demchenko]

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.
 >
Consider this as mandatory (?) Security consideration as explained above.

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