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

[Donal K. Fellows]

Yuri Demchenko wrote:
> 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

I'm tempted to point out that those two documents merely describe the
limitations of one particular XSL system, and that they assume that
there is no non-performance reason for choosing one XML representation
over another.

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

The problem is that it directly conflicts with what we need elsewhere.
This is probably due to the fact that this is an evolving standard and
we're going to be following a policy of "release early, release often"
approach instead of "define everything we will ever need". Given that we
know we won't scope things perfectly to start out with, locking down in
the way you think we should would be a very bad move.

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

The key is that the secure credentials and signing lie at the layer that
*contains* the JSDL (or higher up). It's possible that some processing
elements won't care about such things because they know more about the
processing context (e.g. secured connection from an agent that is
trusted to establish these sorts of security conditions) and indeed I'd
suggest that any document delivered in a way that does not establish
trust in what it says ought to be rejected. But the doing of that is
outside the actual scope of JSDL, and we have use-cases where that
highly trusted context really is established.

Donal.