[jsdl-wg] XSD Schema - latest

[Yuri Demchenko]

Andrew Stephen McGough wrote:
> 
> Here is the latest XSD schema. Think I've got all the new stuff in that
> people wanted.
> 
> I'll add it to sourceforge.
> 
Look good.

However, for my first look schema presentation needs some optimisation 
on the following issues:

1) consider moving some of child elements to attribute

Rationale: this actually should improve readability and programming

2) consider moving attributes definition/enumeration to the end of the 
schema - for better readability

3) consider having all elements' name capitalised and attributes 
preferably starting from small letter

4) consider moving enumerated elements like LimitTypeEnumeration or 
OSenumeration to attributes

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.

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>

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>

8) the same approach can be applied to the Limit element and some other

8) consider changing the User element definition and consider the 
following issues:

- How ExecutionUserID relates to UserCredential
* is nameId the same?
* how they are connected semantically and cryptographically?
* who assigns user groups and they are confirmed

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>

----

Hope this will have some value for you.

We are considering using JSDL format in some our projects and 
following JSDL development.

Regards,

Yuri

P.S. Example of XMLWebService definition for Grid Security Incident 
definition you can find in IODEF-XWS profile at
http://www.uazone.org/demch/projects/iodef/draft-ietf-inch-iodef-042-xws.xsd
http://www.uazone.org/demch/projects/iodef/index.html