[jsdl-wg] XSD Schema - latest

[Andrew Stephen McGough]

Hi Yuri,

Thanks for the comments. I can't remember are you at GGF this week? We 
have two more sessions tomorrow and I'd like to put your ideas infront 
of the group during them.

cheers,

steve..

Yuri Demchenko wrote:

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


-- 
--
------------------------------------------------------------------------
Dr A. Stephen McGough                       http://www.doc.ic.ac.uk/~asm
------------------------------------------------------------------------
Technical Coordinator, London e-Science Centre, Imperial College London,
Department of Computing, 180 Queen's Gate, London SW7 2BZ, UK
tel: +44 (0)207-594-8409                        fax: +44 (0)207-581-8024
------------------------------------------------------------------------
Assistant Warden, West Wing, Beit Hall, Imperial College,
Prince Consort Road, London, SW7 2BB            tel: +44 (0)207-594-9910
------------------------------------------------------------------------