Folks, from the last phone conference, I had the action assigned to follow the suggestion of naming elements. Based on some thinking and toying around, I propose the following layout: JSDL allows to define a) applications that are supposed to be executed, b) sets of resources that are to be consumed, c) files to be staged in and out and, finally, d) establishes associations between applications, resources and data sets. An exhaustive 3-tuple of associations is called "JobDescription". A JobDescription can also contain a set of identifiable elements serving various kind of purposes, such as accounting, billing, etc. These elements are aggregated in an element called "JobIdentification". All this is aggregated in a root element called "JobDefinition" (a name I would like to question, but more on this at a later point). This short description from a bird's eye view may not be totally new, but it gives some valuable hints on what is worth being referencable and what not: a) resources, b) applications and c) data sets. A JobDescription does not necessarily has to be referencable, since it is usually a unique association between other elements that, in this configuration, serve a unique purpose. It is adequatically specified through the document's namespace. Similar jobs (who have a different namespace) may want to use exactly the same set of resources or the same application etc. Most likely, however, the resource sets or applications etc. that have been defined for another job will not fit exactly the new job's needs, so a mechanism to tweak existing definitions could be handy. So, more technically and closer to the spec/schema, the following elements should be made referencable: - /JobDefinition/JobDescription/Application - /JobDefinition/JobDescription/Resource - /JobDefinition/JobDescription/DataStaging - Additionally, a similar mechanism exists for /JobDefinition/JobDescription/Resource/FileSystem and /JobDefinition/JobDescription/DataStaging/FileSystemID. I also propose to change FileSystemID to the type xsd:QName. - Following the convention used with the construct "xsd:group", I propose to use an attribute "name" of type "xsd:NCName" to make an element referencable. An attribute named "ref" of type "xsd:QName" is proposed to be used as a reference to a referencable element. - Sibling to JobDescription, applications, resource sets and data staging elements are allowed to be specified. They all get an attribute "name" of type "xsd:NCName" to be made referencable. - JobDescription defines local elements(!) with the same name (for applications, resource sets and data staging) and each gets an optional attribute named "ref" of type "xsd:QName" to refer to already defined elements (either in the same document, or externally). - These locally defined elements allow exactly the same appropriate groups of elements as the elements sibling to JobDescription. - Elements specified in JobDescription's local elements override elements with the same name in referred elements. - Finally, I propose to change the name of "JobDefinition" to something else, e.g. "JSDL" or something that does *not* have "Job" in its name since it does not define jobs alone anymore. (I just have no clue on a reasonable replacement.) The following proposals are of more concern to schema hackers and are related to technical issues of design and "taste". They can easily be skipped by others although they may touch higher level concerns: - I further propose to follow one of the two scenarios: a) define exactly one global element ("JobDefinition") so that any valid JSDL document always has "JobDefinition" as root element b) define a limited number of global elements, i.e. JobDefinition, JobDescription, Resource (rename to "ResourceSet"?) Application and DataStaging so that any valid JSDL document may have any of these globally defined elements as root element - Any other elements and types should be locally defined. Or do we want to allow i.e. "jsdl:NetworkBandwidth" to be root element? - Use xsd:group to group elements together and refer to these groups instead of repeating element definitions Cheers, Michel
Sorry, I can not understand most of comments and statements here. Maybe explanation how most of these changes can improve understanding or schema definition would help. Michel Drescher wrote:
Folks,
from the last phone conference, I had the action assigned to follow the suggestion of naming elements.
Based on some thinking and toying around, I propose the following layout:
JSDL allows to define a) applications that are supposed to be executed, b) sets of resources that are to be consumed, c) files to be staged in and out and, finally, d) establishes associations between applications, resources and data sets. An exhaustive 3-tuple of associations is called "JobDescription". A JobDescription can also contain a set of identifiable elements serving various kind of purposes, such as accounting, billing, etc. These elements are aggregated in an element called "JobIdentification". All this is aggregated in a root element called "JobDefinition" (a name I would like to question, but more on this at a later point). This short description from a bird's eye view may not be totally new, but it gives some valuable hints on what is worth being referencable and what not: a) resources, b) applications and c) data sets. A JobDescription does not necessarily has to be referencable, since it is usually a unique association between other elements that, in this configuration, serve a unique purpose. It is adequatically specified through the document's namespace. Similar jobs (who have a different namespace) may want to use exactly the same set of resources or the same application etc. Most
Sorry for my ignorance, why and when this may happen that "Similar jobs (who have a different namespace)"? Completely different? Can it be solved by using imported namespaces and extension mechanism?
likely, however, the resource sets or applications etc. that have been defined for another job will not fit exactly the new job's needs, so a mechanism to tweak existing definitions could be handy.
So, more technically and closer to the spec/schema, the following elements should be made referencable: - /JobDefinition/JobDescription/Application - /JobDefinition/JobDescription/Resource - /JobDefinition/JobDescription/DataStaging - Additionally, a similar mechanism exists for /JobDefinition/JobDescription/Resource/FileSystem and /JobDefinition/JobDescription/DataStaging/FileSystemID. I also propose to change FileSystemID to the type xsd:QName.
What does it mean referenceable? IMHO, you can reference with ID/Id attribute or with XPath or with xpointer any legitimate element in the XML document. Do you mean referencing schema elements/types?
- Following the convention used with the construct "xsd:group", I propose to use an attribute "name" of type "xsd:NCName" to make an element referencable. An attribute named "ref" of type "xsd:QName" is proposed to be used as a reference to a referencable element. - Sibling to JobDescription, applications, resource sets and data staging elements are allowed to be specified. They all get an attribute "name" of type "xsd:NCName" to be made referencable.
can you give an example what you mean by above?
- JobDescription defines local elements(!) with the same name (for applications, resource sets and data staging) and each gets an optional attribute named "ref" of type "xsd:QName" to refer to already defined elements (either in the same document, or externally). - These locally defined elements allow exactly the same appropriate groups of elements as the elements sibling to JobDescription. - Elements specified in JobDescription's local elements override elements with the same name in referred elements.
Sorry I can not understand how/why some elements are qualified as local and what is the incentive of using global vs local elements? If you are talking about definitions like <xsd:element name="Description" type="jsdl:description" minOccurs="0"/> this I can understand.
- Finally, I propose to change the name of "JobDefinition" to something else, e.g. "JSDL" or something that does *not* have "Job" in its name since it does not define jobs alone anymore. (I just have no clue on a reasonable replacement.)
The following proposals are of more concern to schema hackers and are related to technical issues of design and "taste". They can easily be skipped by others although they may touch higher level concerns:
- I further propose to follow one of the two scenarios: a) define exactly one global element ("JobDefinition") so that any valid JSDL document always has "JobDefinition" as root element b) define a limited number of global elements, i.e. JobDefinition, JobDescription, Resource (rename to "ResourceSet"?) Application and DataStaging so that any valid JSDL document may have any of these globally defined elements as root element
How above is related to the schema attributes elementFormDefault and AttributeFormDefault? What is the reason of limiting number of global elements? What is the benefits of having local elements? Does it help implementation/programming?
- Any other elements and types should be locally defined. Or do we want to allow i.e. "jsdl:NetworkBandwidth" to be root element?
- Use xsd:group to group elements together and refer to these groups instead of repeating element definitions
There should be some reason to group some elements except referencing them together. How many these cases of repeated definitions you have? Sorry I am really confused. Yuri
Cheers, Michel
------------------------------------------------------------------------
This text file carries explanations for the exammple given for the proposal of a new schema layout.
Package contents ================ job.xsd - the schema defining a simple JSDL inspired job structure example.xml - a sample XML document following the job.xsd schema exmple2.xml - another sample XL document following the same schema as examle.xml. Additionally it uses more advanced features like referring to elements defined in example.xml, and the usage of POSIXApplication that is part of the JSDL specification. readme.txt - this file
job.xsd ======= This schema defines a bunch of element types and elements. In particular and in order of appearance in the schema:
MemoryType ---------- A simple type of xsd:positiveInteger describing physical memory, in Bytes.
StorageType ----------- A simple type of xsd:positiveInteger describing any sort of storage, in Bytes.
CPUCountType ------------ A simple type of xsd:positiveInteger describing an amount of CPUs
ResourceGroup ------------- A xsd:group structure containing zero to three elements, each of type MemoryType, StorageType, or CPUCountType, respectively, so that each type occurs only once in this group.
ResourceType ------------ A complex type allowing elements of the group ResourceGroup. Additionally, it has an attribute of type xsd:NCName for the purpose of (possibly external) referencability.
ExecutableType -------------- A simple type defining how to speciify an executable.
ArgumenntType ------------- A simple type defining the structure of a command line parameter.
EnvironmentType --------------- A simple type defining the structure of environment variables
ApplicationGroup ---------------- A group collecting elements of type ExecutableType, ArgumentType and EnvironmentType. Same constraints from ResourceGroup apply.
ApplicationType ---------------- A complex type allowing elements of the ApplicationGroup to appear inside. Additionally, for referencability, it has an attribute "name" of type xsd:NCName.
JobType ------- A complex type defining the associations between Resources and an application. It defines two local elements "Resource" and "Application" (so that they do not need a namespace qualifier and cannot be root elements), both being complex types allowing elements of the group ResourceGroup and ApplicationGroup, respectively. They also define an attrbute of type xsd:QName each. Additionally, the local element "Application" allows for extension just as JSDL does (by allowing any XML element from other namespaces).
Jobs ---- This is the only globally defined element in this schema. Thus any document following this schema must have "Jobs" as root element. Jobs defines three local elements named "Resource", "Application" and "Job" that are of type "ResourceType", "ApplicationType" and "JobType", respectively. It also allows arbitrary attributes of any namespace.
example.xml =========== This sample XML document defines a set of resources named "AnySuitableComputer" (you will notice the inspiration from Igor's proposal...) and an application named "MonteCarlo" (same goes here...). It finally defines a Job that associates the resources "AnySuitableComputer" with the application "MonteCarlo". Note that the QNames must be given using the target namespace prefix ("ex" in this case) even if the referred elements are declared in the same document.
example2.xml ============ This example defines a customised version of example.xml. It uses the same set of resources, but overrides the value for Storage (since this version happens to need more storage space, for the sake of this example). Also, it uses the same application definition. Additionally, it uses a POSIXApplication extension to be able to use a POSIX specific version off the Monte Carlo simulation. This bit of this example is somewhat artificial since it now specifies two Executable elements and it is unclear which one the consuming system should use. But after all, it's just an example. :-)
On Apr 07, Yuri Demchenko loaded a tape reading:
Sorry, I can not understand most of comments and statements here.
Maybe explanation how most of these changes can improve understanding or schema definition would help.
I am trying to answer and reiterate some of the many questions below w/ inline comments...
Michel Drescher wrote: ...
A JobDescription does not necessarily has to be referencable, since it is usually a unique association between other elements that, in this configuration, serve a unique purpose. It is adequatically specified through the document's namespace. Similar jobs (who have a different namespace) may want to use exactly the same set of resources or the same application etc. Most
Sorry for my ignorance, why and when this may happen that "Similar jobs (who have a different namespace)"?
Completely different? Can it be solved by using imported namespaces and extension mechanism?
Michel is not talking about namespaces for schema, but for instance documents. He intends to mark up elements in an instance document with NCName attributes and refer to them in a global context by qualifying those names w/ the target namespace of the instance document within which the name is introduced. Michel means that an instance document may want to reference subdocuments such as application, data, etc., from another instance document. These documents may exist in different target namespaces. The terminology around XML and XSD is unfortunate for people often being ambiguous as to whether they mean "some XML element instance" or "an XSD element declaration" when they say the word "element"...
What does it mean referenceable?
IMHO, you can reference with ID/Id attribute or with XPath or with xpointer any legitimate element in the XML document.
Do you mean referencing schema elements/types?
As I hope I clarified above, Michel means "named by an instance-unique NCName in a well-defined target namespace" when he says "referenceable". I agree that the motivation for this complicated discussion seems weak, as there are existing structural reference mechanisms like XPath which work without special support in the instance schema.
- JobDescription defines local elements(!) with the same name (for applications, resource sets and data staging) and each gets an optional attribute named "ref" of type "xsd:QName" to refer to already defined elements (either in the same document, or externally). - These locally defined elements allow exactly the same appropriate groups of elements as the elements sibling to JobDescription. - Elements specified in JobDescription's local elements override elements with the same name in referred elements.
Sorry I can not understand how/why some elements are qualified as local and what is the incentive of using global vs local elements?
If you are talking about definitions like
<xsd:element name="Description" type="jsdl:description" minOccurs="0"/>
this I can understand.
I think Michel made an unfortunate choice of words... I _think_ he is resurrecting the Profile mechanism which was removed at GGF-13, by suggesting how an instance document would reference another (using the naming mechanism described above) and then "override" some of its content by providing its own content with the same names. In essence, he is trying to define a semantics for JSDL documents based on rewrite rules for merging the referenced document and the referencing document to yield a new result document that validates to the JSDL schema but no longer has the external references.
The following proposals are of more concern to schema hackers and are related to technical issues of design and "taste". They can easily be skipped by others although they may touch higher level concerns:
- I further propose to follow one of the two scenarios: a) define exactly one global element ("JobDefinition") so that any valid JSDL document always has "JobDefinition" as root element b) define a limited number of global elements, i.e. JobDefinition, JobDescription, Resource (rename to "ResourceSet"?) Application and DataStaging so that any valid JSDL document may have any of these globally defined elements as root element
How above is related to the schema attributes elementFormDefault and AttributeFormDefault?
What is the reason of limiting number of global elements? What is the benefits of having local elements?
Does it help implementation/programming?
I also question the goal of limiting the number of global elements. I think exposing most of the JSDL concepts (the job ontology) as global elements is a good thing, to encourage others to reuse the syntax instead of copying their own when they decide we were silly for trying to control the use of our definitions. I think the only justification for local element declarations in a standard like this is when the elements are not meaningful outside the context of their defined use. For example, it makes sense to me if the children of a JSDL range type would not be global elements, because the range boundary is not really meaningdul outside the context of the range.
- Any other elements and types should be locally defined. Or do we want to allow i.e. "jsdl:NetworkBandwidth" to be root element?
I don't see any reason not to make any of our resource terms global elements. I think we must purge from our minds the idea that there is a "JSDL document". There is a JSDL Specification which defines a family of documents such as jsdl:JobDefinition. If you want to talk about a JSDL document, you need to define a "JSDL" element! Every XML element is a document, once you embrace the universe as an infoset. :-) karl
- Use xsd:group to group elements together and refer to these groups instead of repeating element definitions
There should be some reason to group some elements except referencing them together. How many these cases of repeated definitions you have?
Sorry I am really confused.
Yuri
-- Karl Czajkowski karlcz@univa.com
Karl, Thank you very much, useful explanation. So, now I don't have question marks but mostly agreement with your comments. In summary, I support your statement about benefits of having all elements global and belonging to the "jsdl" namespace. I don't see a problem in general in referencing external instance-document's content by element's ID, xpath or xpointer. I can also understand removing Profile from the JobDefinition. It is indeed better suitable for WS-Agreement than for JSDL. Just from our experience of programming schemas in Java, I would avoid this kind of definitions <xsd:element name="Description" type="jsdl:description" minOccurs="0"/> where elements/types differ by capital letters. Also there are some tricks, at least in Java DOM libraries, when you need to add/combine external elements with different namespaces. Thanks, Yuri Karl Czajkowski wrote:
On Apr 07, Yuri Demchenko loaded a tape reading:
Sorry, I can not understand most of comments and statements here.
Maybe explanation how most of these changes can improve understanding or schema definition would help.
I am trying to answer and reiterate some of the many questions below w/ inline comments...
Michel Drescher wrote:
...
A JobDescription does not necessarily has to be referencable, since it is usually a unique association between other elements that, in this configuration, serve a unique purpose. It is adequatically specified through the document's namespace. Similar jobs (who have a different namespace) may want to use exactly the same set of resources or the same application etc. Most
Sorry for my ignorance, why and when this may happen that "Similar jobs (who have a different namespace)"?
Completely different? Can it be solved by using imported namespaces and extension mechanism?
Michel is not talking about namespaces for schema, but for instance documents. He intends to mark up elements in an instance document with NCName attributes and refer to them in a global context by qualifying those names w/ the target namespace of the instance document within which the name is introduced.
Michel means that an instance document may want to reference subdocuments such as application, data, etc., from another instance document. These documents may exist in different target namespaces.
The terminology around XML and XSD is unfortunate for people often being ambiguous as to whether they mean "some XML element instance" or "an XSD element declaration" when they say the word "element"...
What does it mean referenceable?
IMHO, you can reference with ID/Id attribute or with XPath or with xpointer any legitimate element in the XML document.
Do you mean referencing schema elements/types?
As I hope I clarified above, Michel means "named by an instance-unique NCName in a well-defined target namespace" when he says "referenceable".
I agree that the motivation for this complicated discussion seems weak, as there are existing structural reference mechanisms like XPath which work without special support in the instance schema.
- JobDescription defines local elements(!) with the same name (for applications, resource sets and data staging) and each gets an optional attribute named "ref" of type "xsd:QName" to refer to already defined elements (either in the same document, or externally). - These locally defined elements allow exactly the same appropriate groups of elements as the elements sibling to JobDescription. - Elements specified in JobDescription's local elements override elements with the same name in referred elements.
Sorry I can not understand how/why some elements are qualified as local and what is the incentive of using global vs local elements?
If you are talking about definitions like
<xsd:element name="Description" type="jsdl:description" minOccurs="0"/>
this I can understand.
I think Michel made an unfortunate choice of words... I _think_ he is resurrecting the Profile mechanism which was removed at GGF-13, by suggesting how an instance document would reference another (using the naming mechanism described above) and then "override" some of its content by providing its own content with the same names. In essence, he is trying to define a semantics for JSDL documents based on rewrite rules for merging the referenced document and the referencing document to yield a new result document that validates to the JSDL schema but no longer has the external references.
The following proposals are of more concern to schema hackers and are related to technical issues of design and "taste". They can easily be skipped by others although they may touch higher level concerns:
- I further propose to follow one of the two scenarios: a) define exactly one global element ("JobDefinition") so that any valid JSDL document always has "JobDefinition" as root element b) define a limited number of global elements, i.e. JobDefinition, JobDescription, Resource (rename to "ResourceSet"?) Application and DataStaging so that any valid JSDL document may have any of these globally defined elements as root element
How above is related to the schema attributes elementFormDefault and AttributeFormDefault?
What is the reason of limiting number of global elements? What is the benefits of having local elements?
Does it help implementation/programming?
I also question the goal of limiting the number of global elements. I think exposing most of the JSDL concepts (the job ontology) as global elements is a good thing, to encourage others to reuse the syntax instead of copying their own when they decide we were silly for trying to control the use of our definitions. I think the only justification for local element declarations in a standard like this is when the elements are not meaningful outside the context of their defined use. For example, it makes sense to me if the children of a JSDL range type would not be global elements, because the range boundary is not really meaningdul outside the context of the range.
- Any other elements and types should be locally defined. Or do we want to allow i.e. "jsdl:NetworkBandwidth" to be root element?
I don't see any reason not to make any of our resource terms global elements. I think we must purge from our minds the idea that there is a "JSDL document". There is a JSDL Specification which defines a family of documents such as jsdl:JobDefinition. If you want to talk about a JSDL document, you need to define a "JSDL" element! Every XML element is a document, once you embrace the universe as an infoset. :-)
karl
- Use xsd:group to group elements together and refer to these groups instead of repeating element definitions
There should be some reason to group some elements except referencing them together. How many these cases of repeated definitions you have?
Sorry I am really confused.
Yuri
[I have tried to trim the message down as hard as I can; some attribution info has definitely been lost, along with much context.] Karl Czajkowski wrote:
What does it mean referenceable? IMHO, you can reference with ID/Id attribute or with XPath or with xpointer any legitimate element in the XML document. Do you mean referencing schema elements/types?
As I hope I clarified above, Michel means "named by an instance-unique NCName in a well-defined target namespace" when he says "referenceable".
I agree that the motivation for this complicated discussion seems weak, as there are existing structural reference mechanisms like XPath which work without special support in the instance schema.
The problem with IDs or XPath terms is that neither of them supports references to externally-defined terms. (I'm also not convinced that IDs goes nicely with document composition and XML signatures/encryption.) Our favoured mechanism is also that which is used in XSD and WSDL, for what it's worth (and I've no idea why they don't use xpointer, but if we went that way you would *still* need substantial tooling support). All this makes much more sense once you start building larger documents containing JSDL jobs (yeah, I know I'm using the term loosely).
Sorry I can not understand how/why some elements are qualified as local and what is the incentive of using global vs local elements?
If you are talking about definitions like <xsd:element name="Description" type="jsdl:description" minOccurs="0"/> this I can understand.
[Side Q: Should JobDescription be renamed to avoid confusion with Description?]
I think Michel made an unfortunate choice of words... I _think_ he is resurrecting the Profile mechanism which was removed at GGF-13, by suggesting how an instance document would reference another (using the naming mechanism described above) and then "override" some of its content by providing its own content with the same names. In essence, he is trying to define a semantics for JSDL documents based on rewrite rules for merging the referenced document and the referencing document to yield a new result document that validates to the JSDL schema but no longer has the external references.
As I understand it, Michel is not referring to a profile mechanism at all. Instead, the mechanism is a way of allowing a job to refer to externally provided resource, application and data-transfer descriptions. There is always to be a possible simple transform applyable to the document that removes such references and produces a "grounded" document by elements that are references with the elements that those references indicate.
The following proposals are of more concern to schema hackers and are related to technical issues of design and "taste". They can easily be skipped by others although they may touch higher level concerns:
- I further propose to follow one of the two scenarios: a) define exactly one global element ("JobDefinition") so that any valid JSDL document always has "JobDefinition" as root element
I think it can easily be that way by definition. Not that it will constrain users of the spec in any way. There is no way to actually stop any user of the XSD from referring to any named thing directly, and nor should we try. (I suspect that only the sub-elements of the range type are not usefully usable outside our normative context.)
b) define a limited number of global elements, i.e. JobDefinition, JobDescription, Resource (rename to "ResourceSet"?) Application and DataStaging so that any valid JSDL document may have any of these globally defined elements as root element
How above is related to the schema attributes elementFormDefault and AttributeFormDefault?
It's completely unrelated. If you want to write out QNames in full each time, feel free. But we'll continue to get lazy in email... :^)
- Any other elements and types should be locally defined. Or do we want to allow i.e. "jsdl:NetworkBandwidth" to be root element?
I don't see any reason not to make any of our resource terms global elements. I think we must purge from our minds the idea that there is a "JSDL document". There is a JSDL Specification which defines a family of documents such as jsdl:JobDefinition. If you want to talk about a JSDL document, you need to define a "JSDL" element! Every XML element is a document, once you embrace the universe as an infoset. :-)
There is a JSDL document, which refers to a conformant JobDefinition element, and then there's the JSDL infoset which is all the elements defined in JSDL. You can meaningfully talk about a NetworkBandwidth element in isolation, but it has to be remembered that it is still a request for resource allocation for some purpose, even if it does not have the full structure around it. Donal.
I think what I said before sounded too metaphysical. I advocate a pragmatic approach of practicing to only talk about concrete things: 1. the JSDL Specification document, a human-consumed deliverable of the JSDL-WG 2. the document types defined in (1) 3. instance documents rooted by specific elements among (2) It seems counterproductive and confusing to try to talk about a "JSDL document" as some blessed thing that is not part of the normative syntax of the specification. Let's just take that extra few key-presses to type "JobDefinition document" or whatever specific element we are intending, and avoid lots of confusing discussions. :-) karl On Apr 07, Donal K. Fellows loaded a tape reading: ...
There is a JSDL document, which refers to a conformant JobDefinition element, and then there's the JSDL infoset which is all the elements defined in JSDL. You can meaningfully talk about a NetworkBandwidth element in isolation, but it has to be remembered that it is still a request for resource allocation for some purpose, even if it does not have the full structure around it.
Donal.
-- Karl Czajkowski karlcz@univa.com
Donal K. Fellows wrote:
The problem with IDs or XPath terms is that neither of them supports references to externally-defined terms. (I'm also not convinced that IDs goes nicely with document composition and XML signatures/encryption.) Our favoured mechanism is also that which is used in XSD and WSDL, for what it's worth (and I've no idea why they don't use xpointer, but if we went that way you would *still* need substantial tooling support).
I can ensure you that ID's work perfectly with all DOM versions and XMLSec. XPath requires special support but it is unavoidable for new XMLSec Java library. Yuri
On Apr 07, Donal K. Fellows loaded a tape reading: ...
As I understand it, Michel is not referring to a profile mechanism at all. Instead, the mechanism is a way of allowing a job to refer to externally provided resource, application and data-transfer descriptions. There is always to be a possible simple transform applyable to the document that removes such references and produces a "grounded" document by elements that are references with the elements that those references indicate.
I cannot resolve that with the points where he went into some detail about the referer having "local elements with the same names" that would "override" those in the referant document. I do not object to the NCName attribute as it is rather benign and straightforward, once we stop stumbling over discussion points like namespaces and instance versus schema elements... but I would think that the outcome of the GGF-13 decision to put Profiles out of scope in an enclosing context for JSDL means we do not try to define reference model and rewrite/merging semantics. Such a thing belongs in the specification for the enclosing context document(s). karl -- Karl Czajkowski karlcz@univa.com
Hi all, firstly, I think I have to apologize for using misleading vocabulary. But after all, I can accu^H^H^H^Hexcuse myself for not being a native English speaker. ;-) I will try to be more accurate in the future. Now, on topic, with comments/corrections inlined below: On 7 Apr 2005, at 9:33, Karl Czajkowski wrote:
On Apr 07, Yuri Demchenko loaded a tape reading:
Sorry, I can not understand most of comments and statements here.
Maybe explanation how most of these changes can improve understanding or schema definition would help.
I am trying to answer and reiterate some of the many questions below w/ inline comments...
Michel Drescher wrote: ...
A JobDescription does not necessarily has to be referencable, since it is usually a unique association between other elements that, in this configuration, serve a unique purpose. It is adequatically specified through the document's namespace. Similar jobs (who have a different namespace) may want to use exactly the same set of resources or the same application etc. Most
Sorry for my ignorance, why and when this may happen that "Similar jobs (who have a different namespace)"?
Completely different? Can it be solved by using imported namespaces and extension mechanism?
Michel is not talking about namespaces for schema, but for instance documents. He intends to mark up elements in an instance document with NCName attributes and refer to them in a global context by qualifying those names w/ the target namespace of the instance document within which the name is introduced.
Yes, exactly.
Michel means that an instance document may want to reference subdocuments such as application, data, etc., from another instance document. These documents may exist in different target namespaces.
What does it mean referenceable?
IMHO, you can reference with ID/Id attribute or with XPath or with xpointer any legitimate element in the XML document.
Do you mean referencing schema elements/types?
As I hope I clarified above, Michel means "named by an instance-unique NCName in a well-defined target namespace" when he says "referenceable".
I agree that the motivation for this complicated discussion seems weak, as there are existing structural reference mechanisms like XPath which work without special support in the instance schema.
Isn't exactly this the purpose of the data type QName? Maybe it's the lack of knowledge on my side, but if I have two instance documents, and instance document one defines elements that I want to reuse in instance document two, the natural built-in thing to use is a pair of NCName and QName typed attributes. Our perspectives on this are different, I think. If I get this right, then you have a XML processor in mind that needs to resolve a reference from one XML instance document to another XML instance document. For this purpose, XPath is certainly an appropriate instrument to actually pick an element from he referent XML instance document using information gathered from the referring XML instance document. But IMHO XPath/XQuery is not appropriate to model a relationship between two XML instance documents - to me, this is done using NCName and QName pairs. (If you want to refer to elements within a XML instance document, ID and IDREF data types might be more appropriate).
- JobDescription defines local elements(!) with the same name (for applications, resource sets and data staging) and each gets an optional attribute named "ref" of type "xsd:QName" to refer to already defined elements (either in the same document, or externally). - These locally defined elements allow exactly the same appropriate groups of elements as the elements sibling to JobDescription. - Elements specified in JobDescription's local elements override elements with the same name in referred elements.
Sorry I can not understand how/why some elements are qualified as local and what is the incentive of using global vs local elements?
If you are talking about definitions like
<xsd:element name="Description" type="jsdl:description" minOccurs="0"/>
this I can understand.
I think Michel made an unfortunate choice of words... I _think_ he is resurrecting the Profile mechanism which was removed at GGF-13, by suggesting how an instance document would reference another (using the naming mechanism described above) and then "override" some of its content by providing its own content with the same names. In essence, he is trying to define a semantics for JSDL documents based on rewrite rules for merging the referenced document and the referencing document to yield a new result document that validates to the JSDL schema but no longer has the external references.
No. I did not intend to resurrect the Profiles mechanism at all. But I admit that the concepts are similar. Profiles were inherently complex while the stuff I suggested implied simple "search and replace" processing. [In that respect the ending part of the quoted paragraph is right, but I didn't want to rip it into pieces.]
The following proposals are of more concern to schema hackers and are related to technical issues of design and "taste". They can easily be skipped by others although they may touch higher level concerns:
- I further propose to follow one of the two scenarios: a) define exactly one global element ("JobDefinition") so that any valid JSDL document always has "JobDefinition" as root element b) define a limited number of global elements, i.e. JobDefinition, JobDescription, Resource (rename to "ResourceSet"?) Application and DataStaging so that any valid JSDL document may have any of these globally defined elements as root element
How above is related to the schema attributes elementFormDefault and AttributeFormDefault?
What is the reason of limiting number of global elements? What is the benefits of having local elements?
Does it help implementation/programming?
I also question the goal of limiting the number of global elements. I think exposing most of the JSDL concepts (the job ontology) as global elements is a good thing, to encourage others to reuse the syntax instead of copying their own when they decide we were silly for trying to control the use of our definitions. I think the only justification for local element declarations in a standard like this is when the elements are not meaningful outside the context of their defined use. For example, it makes sense to me if the children of a JSDL range type would not be global elements, because the range boundary is not really meaningdul outside the context of the range.
It depends on what you want to allow. In "ontology mode" (if I may say so), JSDL certainly should use as much global elements as possible. But in "document mode" (which, as I perceived, has been the major if not sole construction mode being in mind of the group members) a job description as a XML instance document is the focal point of the schema. Still, you can encourage others to use the data types defined by JSDL by making these data types global.
- Any other elements and types should be locally defined. Or do we want to allow i.e. "jsdl:NetworkBandwidth" to be root element?
I don't see any reason not to make any of our resource terms global elements. I think we must purge from our minds the idea that there is a "JSDL document".
Again, this is true if JSDL-WG really wants to define an ontology. If indeed this is the main driver for the group, then I deeply apologize for my misconception.
There is a JSDL Specification which defines a family of documents such as jsdl:JobDefinition. If you want to talk about a JSDL document, you need to define a "JSDL" element! Every XML element is a document, once you embrace the universe as an infoset. :-)
Again, the specification (to my understanding) does NOT define an ontology. It clearly states the parent child relationships between the elements, for example a "[jsdl:Application element] MUST be a sub-element of the JobDescription element." (draft-ggf-jsdl-spec-0.9.5-01.doc, ch. 5.4.1.1).
- Use xsd:group to group elements together and refer to these groups instead of repeating element definitions
There should be some reason to group some elements except referencing them together. How many these cases of repeated definitions you have?
In fact, elements in xsd:group definitions are strongly related to each other. Groups certainly would have been handy back then when Profiles still were part of the specification. However, I intended to express this tight relation of certain elements via the usage of xsd:groups (and not just to use fancy schema elements and save some space). Sorry if I have been too unclear in this point, too. Cheers, Michel
Michel Drescher wrote:
- Any other elements and types should be locally defined. Or do we want to allow i.e. "jsdl:NetworkBandwidth" to be root element?
I don't see any reason not to make any of our resource terms global elements. I think we must purge from our minds the idea that there is a "JSDL document".
Again, this is true if JSDL-WG really wants to define an ontology. If indeed this is the main driver for the group, then I deeply apologize for my misconception.
There is a JSDL Specification which defines a family of documents such as jsdl:JobDefinition. If you want to talk about a JSDL document, you need to define a "JSDL" element! Every XML element is a document, once you embrace the universe as an infoset. :-)
Again, the specification (to my understanding) does NOT define an ontology. It clearly states the parent child relationships between the elements, for example a "[jsdl:Application element] MUST be a sub-element of the JobDescription element." (draft-ggf-jsdl-spec-0.9.5-01.doc, ch. 5.4.1.1).
It is this message/discussion that I was referring to during the telecon. Examining the current spec indicates that we do not define an ontology, and this is because we specify what elements must contain other elements. By dropping the reference from element definitions to their parents (as used in a job-defining document) we can define an ontology *as well*. Sounds like a win all round to me. Donal.
Donal, On 14 Apr 2005, at 9:10, Donal K. Fellows wrote:
There is a JSDL Specification which defines a family of documents such as jsdl:JobDefinition. If you want to talk about a JSDL document, you need to define a "JSDL" element! Every XML element is a document, once you embrace the universe as an infoset. :-) Again, the specification (to my understanding) does NOT define an ontology. It clearly states the parent child relationships between the elements, for example a "[jsdl:Application element] MUST be a sub-element of the JobDescription element." (draft-ggf-jsdl-spec-0.9.5-01.doc, ch. 5.4.1.1).
It is this message/discussion that I was referring to during the telecon.
Examining the current spec indicates that we do not define an ontology, and this is because we specify what elements must contain other elements. By dropping the reference from element definitions to their parents (as used in a job-defining document) we can define an ontology *as well*. Sounds like a win all round to me.
In this respect I fully agree. I am not objecting the idea of defining an ontology at all. It is simply the fact that changing the spec to define an ontology will cause quite some text changes and general reorganisation of the specifcation document itself. I'd rather postpone this to a later JSDL version. Cheers, Michel
Perhaps I am being too informal for your liking, but I think the JSDL specificaiton is intrinsically defining an ontology of jobs already, i.e. what are the meaningful concepts of jobs that can be submitted. The semantics of the various JSDL XML bits are described in English using this implied ontology. Anyone can read the specification and write out the set of concepts into their favorite formalism. What makes it an ontology is its "job-space characterization nature", rather than it being written one way or another! The only question is how explicitly will the specification call out this fact? If it does nothing, there is an implicit ontology being presented. The spec could pay a little respect to the ontology-obsessed by calling out the various concepts or tabulating them somehow. It could encourage reuse by tweaking the XML schema and discussions to emphasize the meaning of "atomic" syntaxes without being tied to the enclosing JSDL document context more than necessary (as I think Donal is suggesting?). At the far other extreme, the specification could try to formalize the ontology using some ontology modeling language. I wholeheartedly agree that there should not be an undertaking here at this time (or ever?). karl On Apr 14, Michel Drescher loaded a tape reading:
It is this message/discussion that I was referring to during the telecon.
Examining the current spec indicates that we do not define an ontology, and this is because we specify what elements must contain other elements. By dropping the reference from element definitions to their parents (as used in a job-defining document) we can define an ontology *as well*. Sounds like a win all round to me.
In this respect I fully agree. I am not objecting the idea of defining an ontology at all. It is simply the fact that changing the spec to define an ontology will cause quite some text changes and general reorganisation of the specifcation document itself. I'd rather postpone this to a later JSDL version.
Cheers, Michel
-- Karl Czajkowski karlcz@univa.com
Karl Czajkowski wrote:
Perhaps I am being too informal for your liking, but I think the JSDL specificaiton is intrinsically defining an ontology of jobs already, i.e. what are the meaningful concepts of jobs that can be submitted. The semantics of the various JSDL XML bits are described in English using this implied ontology. Anyone can read the specification and write out the set of concepts into their favorite formalism. What makes it an ontology is its "job-space characterization nature", rather than it being written one way or another!
We're doing an informal ontology in any case. Formal ontologies are something else. (I work with ontologists, and at some point I need to get JSDL run past one of them. But not until we've got 1.0 shipped.)
The only question is how explicitly will the specification call out this fact? If it does nothing, there is an implicit ontology being presented.
The spec could pay a little respect to the ontology-obsessed by calling out the various concepts or tabulating them somehow. It could encourage reuse by tweaking the XML schema and discussions to emphasize the meaning of "atomic" syntaxes without being tied to the enclosing JSDL document context more than necessary (as I think Donal is suggesting?).
At the far other extreme, the specification could try to formalize the ontology using some ontology modeling language. I wholeheartedly agree that there should not be an undertaking here at this time (or ever?).
I think that the only problem at the moment is that we try to constrain the containing context that elements may be used in as well as constraining the content of those elements. If we just constrain the content, ontological use (as opposed to job-definition use) becomes much easier. I also don't think we actually lose anything; it's just a reordering of the document (and not an alteration to the schema at all). We're probably in huge agreement here :^) Donal.
participants (4)
-
Donal K. Fellows -
Karl Czajkowski -
Michel Drescher -
Yuri Demchenko