[jsdl-wg] Naming elements

[Donal K. Fellows]

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