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