[jsdl-wg] Naming elements

[Yuri Demchenko]

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