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

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

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.

...

* 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

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

I would like to add a few comments in case it can make the next session more lively today. :-) I agree with Donal that some of the attribute versus element concerns are mostly aesthetics or religion, rather than quantifiable improvements that help most or all tooling environments or applications. I also have some concerns about the large enumerations in the current schema, not because I think transcribing an existing concept space is bad, but because our experience in Globus is that enumeration types are not very amenable to use in extensible schema, or in external specifications where we might wish to exploit JSDL. I had stated in a previous session that I thought we should replace the enumerations of platforms, units, etc. w/ QNames, but I discussed it with some of our own XML gurus and they suggested that we should instead simply enumerate a set of normative URIs, one for each "concept" such as "MHz" or "SunOS". For example, we could simply allocate a sub-hierarchy under the JSDL namespace URI, e.g.: http://www.ggf.org/namespaces/2005/03/units/MHz ... http://www.ggf.org/namespaces/2005/03/operatingSystem/Linux ... http://www.ggf.org/namespaces/2005/03/comparison/equalTo which do not correspond to any XSD construct. This is preferrable to QNames for one important reason: having QNames as values in XML causes problems for a class of "untyped" XML rewriters such as are present in WS-Security canonicalization. These generic tools are unable to safely rewrite namespace prefix bindings and prefix references (something they unfortunately have to do to be conformant) without knowing the content model (schema) to distinguish QName value fields from values that just happen to look like QNames. This means the tools need to either fail on such documents, or fall back to a slower "runtime type processing" mode. If we do this, the places that currently have one of the JSDL enumeration types would instead have xsd:anyURI. I think this is an acceptable "loss" in typing precision because it allows other future documents to import JSDL concepts like units, platforms, etc. simply by using our normative concept URIs in the context of their own documents. karl -- Karl Czajkowski karlcz@univa.com

William Lee wrote:

I agree with Karl's suggestion that URIs would be a better representation to name items in an extensible set of 'things'. Although QNames would be fine for things that are unlikely to be changed or represent in other means, such as "frequency". However OperatingSystem and the like are clearly extensible. Use of URI is much closer to ways things are named in other metadata framework, such as RDF.

If URI is used, we just have to clearly enumerate the normative list in the spec. rather than buried inside the XSD schema.

Please, consider also another form of URI - non-URL type (e.g., like used by OASIS in SAML/XACML specifications) http://www.ggf.org/namespaces/2005/03/comparison/equalTo can be also urn:ggf:names:JSDL:0.9:operation:function:equel-to BTW, about functions and operations you can actually import XPath and XMath enumerated types. REgards, Yuri

William

On 16 Mar 2005, at 11:16, Karl Czajkowski wrote:

...

I would like to add a few comments in case it can make the next session more lively today. :-)

I agree with Donal that some of the attribute versus element concerns are mostly aesthetics or religion, rather than quantifiable improvements that help most or all tooling environments or applications.

I also have some concerns about the large enumerations in the current schema, not because I think transcribing an existing concept space is bad, but because our experience in Globus is that enumeration types are not very amenable to use in extensible schema, or in external specifications where we might wish to exploit JSDL. I had stated in a previous session that I thought we should replace the enumerations of platforms, units, etc. w/ QNames, but I discussed it with some of our own XML gurus and they suggested that we should instead simply enumerate a set of normative URIs, one for each "concept" such as "MHz" or "SunOS". For example, we could simply allocate a sub-hierarchy under the JSDL namespace URI, e.g.:

http://www.ggf.org/namespaces/2005/03/units/MHz ... http://www.ggf.org/namespaces/2005/03/operatingSystem/Linux ... http://www.ggf.org/namespaces/2005/03/comparison/equalTo

which do not correspond to any XSD construct. This is preferrable to QNames for one important reason: having QNames as values in XML causes problems for a class of "untyped" XML rewriters such as are present in WS-Security canonicalization. These generic tools are unable to safely rewrite namespace prefix bindings and prefix references (something they unfortunately have to do to be conformant) without knowing the content model (schema) to distinguish QName value fields from values that just happen to look like QNames. This means the tools need to either fail on such documents, or fall back to a slower "runtime type processing" mode.

If we do this, the places that currently have one of the JSDL enumeration types would instead have xsd:anyURI. I think this is an acceptable "loss" in typing precision because it allows other future documents to import JSDL concepts like units, platforms, etc. simply by using our normative concept URIs in the context of their own documents.

karl

-- Karl Czajkowski karlcz@univa.com

--- William Lee @ London e-Science Centre, Imperial College London -- --- Software Coordinator --- A: Room 380, Department of Computing, Imperial College London, Huxley Building, South Kensington campus, London SW7 2AZ, UK E: wwhl@doc.ic.ac.uk | william@imageunion.com W: www.lesc.ic.ac.uk | www.imageunion.com P: +44(0)20 7594 8251 F: +44(0)20 7581 8024

--- Projects ---------------------------- GridSAM: http://www.lesc.ic.ac.uk/gridsam Markets: http://www.lesc.ic.ac.uk/markets ICENI: http://www.lesc.ic.ac.uk/iceni -----------------------------------------