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.