[jsdl-wg] Naming elements

[Michel Drescher]

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