Re: XLink resource confusion (long)

["Eve L. Maler" <eve.maler@east.sun.com>]

[reposting to XML-Dev because it bounced my earlier mail; sorry to David 
for the repost but I wanted him to know what was going on!]

			*		*		*

Hello David,

 > I am confused as to the meaning of 'resource' in the
 > the XLink draft spec [Spec]. I'd be glad of any comments.
 >
 > Quote 1, In [Spec] 2.3:
 >
 >   "Definition: A local resource is an XML element that
 >   participates in a link by virtue of having as its parent,
 >   or being itself, a linking element".
 >
 > That is, a local resource might be either:
 > - Interpretation 1.A: a linking element. Presumably either
 >   a simple or extended link.
 > - Interpretation 1.B: a child of a linking element.
 >
 > Is a third interpretation possible?
 > - Interpretation 1.C: both 1.A and 1.B.

This definition was written to accommodate the situations of both
simple and extended links.  In a simple link, the linking element
itself is a local resource that serves as the starting resource
for the one built-in arc created by that link.  In an extended
link, the resource-type element is a local resource that serves,
in some set of arcs in that link, as the starting resource.

 > Issues:
 > - Is this optional? Do we get to choose?

Nope.

 > - Local resources can only be elements, according to this
 >   definition. That is, text child nodes of linking elements
 >   are not considered resources.

That's correct.  In both cases, the local resource is an XML
element of a particular XLink flavor.

 > How many and what resources are there in the following?:
 >
 >   <par xlink:type="simple"
 >        xlink:href="...">
 >     <title>Bloody Stupid Johnson invented links</title>
 >       B.S Johnson, the Discworld's (reg.) most famous idiot
 >       inventor, was a pioneer of linking in document mark-up
 >       languages. All arcs were in-bound.
 >   </par>
 >
 > How many resources? Possibilities:
 > - 1 resource: namely the 'par' element, presumably with its
 >   contents ('title' and the text).
 >   (Interpretation 1.A)

This is the correct one.  But note that xlink:type="title"
has no particular meaning inside simple linking elements.

 > - 1 resource: the 'title' child element of the 'par' element.
 >   (Interpretation 1.B)
 >
 > - 2 resources: the 'par' element (with or without contents?)
 >   and the 'title' child element (even though this is presumably
 >   already included as a part of the 'par' resource).
 >   (Interpretation 1.C)
 >
 > Note:
 > The only real substance here is the text content of the 'par'
 > element, but by this definition it cannot be classified as
 > a resource. Of course, it is part of the 'par' element, but
 > there is no mention here of descendants of whatever type being
 > part of the resource. Presumably it is so, but is it specifically
 > stated somewhere?

You could use an extended link and create a remote resource that
points back into the par element, if you want, but that's going
kind of far.  If you're only interested in the text content of
an element, your traversal/rendering process would surely take
that into account.

 > Now, turning this example into an extended link:
 >
 >   <par xlink:type="extended">
 >     <title>Bloody Stupid Johnson invented links</title>
 >       B.S Johnson, the Discworld's (reg.) most famous idiot
 >       inventor, was a pioneer of linking in document mark-up
 >       languages. All arcs were in-bound.
 >     <loc xlink:type="locator"
 >          xlink:href="..."/>
 >     <loc xlink:type="locator"
 >          xlink:href="..."/>
 >   </par>

(You probably want one or more arc-type elements in here too, but
maybe not because you could be intending to use the default of
"arcs between everything.")

 > How many resources now? Possibilities:
 >
 > - 1 resource: namely the 'par' element, presumably with its
 >   contents. Only now, the locators form part of the local
 >   resource of the 'par' element instead of (or in addition
 >   to) serving as XLink elements.
 >   (Interpretation 1.A)
 >
 >   This is probably not what is wanted.
 >
 > - 3 resources: the 'title' element, and the two 'loc' elements.
 >   (Interpretation 1.B)
 >
 > - 1 resource: the 'title' child element of the 'par' element.
 >   In this case we have (arbitrarily?) excluded the 'loc'
 >   elements from consideration as resources.
 >   (Interpretation 1.B, with a twist)
 >
 > - 2 resources: the 'par' element (with or without contents?)
 >   and the 'title' child element (even though this is presumably
 >   already included as a part of the 'par' resource).
 >   Again, we have (arbitrarily?) excluded the 'loc' elements
 >   from consideration as resources.
 >   (Interpretation 1.C, with the same twist)

There are exactly two resources: the two locator-type elements.
The extended-type element is the link itself, and the title-type
element is the link title.  You don't have any explicit arcs,
so I don't know which you intend to be starting vs. ending, but
as you have it now, each serves as a starting resource for the
other, and each serves as an ending resource for the other.

 > It is conceivable that it might be useful to know whether the
 > 'title' child element and the text child of the 'par' element
 > are parts of the same resource or instead are one resource
 > (the 'title' element) and part of a second resource ('par').
 >
 > Further complication:
 > Quote 2. In [Spec] 5.1.1 it says:
 >
 >   'An extended link indicates its participating local
 >   resources by means of special subelements that appear
 >   inside the extended link. An entire subelement, together
 >   with all of its contents, makes up a local resource.
 >
 >   The XLink element for local resources is any element with
 >   an attribute in the XLink namespace called type with a
 >   value of "resource".
 >
 >   The resource-type element may have any content; whatever
 >   content is present has no XLink-specified relationship to
 >   the link.'
 >
 > That is:
 > - Local resources are indicated by xlink:type="resource"
 > attributes.
 > - At least here we understand that the contents of a resource
 > element are part of the resource.
 > - Only element child nodes ("subelements"?) can be resources.
 > So once again text content of an extended link cannot be
 > considered a resource?

Correct, unless you define a locator-type element that points
back into the linking element, the title element, the content
of a particular other subelement in there, etc.  This might be
considered "stupid pointing tricks," or it might be something
really clever. :-)

Resource-type elements *are* resources that participate in a link.
Locator-type elements are *references* to resources that participate
in a link.  For discussion purposes, though, it's convenient to
think of the locator-type and resource-type elements in an extended
link as the "set of resources" on which the link operates.

 > This gives:
 > - Interpretation 2: Each subelement of the link which has
 >   attribute xlink:type='resource'.

Correct.

 > Taking the example above:
 >
 >   <par xlink:type="extended">
 >     <title>Bloody Stupid Johnson invented links</title>
 >       B.S Johnson, the Discworld's (reg.) most famous idiot
 >       inventor, was a pioneer of linking in document mark-up
 >       languages. All arcs were in-bound.
 >     <loc xlink:type="locator"
 >          xlink:href="..."/>
 >     <loc xlink:type="locator"
 >          xlink:href="..."/>
 >   </par>
 >
 > What are the resources under interpretation 2? Possibilities:
 >
 > - 0 resource: No xlink:type='resource' elements.
 >
 >   However, at least we can say that the 'loc' elements are not
 >   resources.
 >
 > Changing the example by adding an xlink:type='resource' to
 > the subelements without an xlink:type attribute.
 >
 >   <par xlink:type="extended">
 >     <title xlink:type="resource">
 >       Bloody Stupid Johnson invented links
 >     </title>
 >       B.S Johnson, the Discworld's (reg.) most famous idiot
 >       inventor, was a pioneer of linking in document mark-up
 >       languages. All arcs were in-bound.
 >     <loc xlink:type="locator"
 >          xlink:href="..."/>
 >     <loc xlink:type="locator"
 >          xlink:href="..."/>
 >   </par>
 >
 > Result is that we now have the title as a resource of the
 > extended link. But we cannot indicate that the text of the
 > 'par' (the substance) is a resource.
 >
 > Note:
 > XLink+XPointer would allow the text content to be indicated
 > as a _remote_ resource.

Yes.

 > Issue:
 > If all sub-elements which are resources need to be named as
 > such using xlink:type='resource' attributes, we can't have
 > resources which contain more than one element. For example,
 > it is not possible to have a resource consisting of multiple
 > 'par' elements, as in this case:
 >
 >   <section xlink:type="extended">
 >     <title xlink:type="resource">
 >       Bloody Stupid Johnson invented links
 >     </title>
 >     <par xlink:type="resource">
 >       B.S Johnson, the Discworld's (reg.) most famous idiot
 >       inventor, was a pioneer of linking in document mark-up
 >       languages. All arcs were in-bound.
 >     </par>
 >     <par xlink:type="resource">
 >       At the time of B.S Johnson there were no computers in
 >       the Discworld (reg). Hyperlinking did not take off in
 >       a big way.
 >     </par>
 >     <loc xlink:type="locator"
 >          xlink:href="..."/>
 >     <loc xlink:type="locator"
 >          xlink:href="..."/>
 >   </section>
 >
 > In this case we may want the two 'par' elements as separate
 > resources, but we might also want them to be one resource.

As mentioned above, making this a remoate resource will do the trick
here.

 > Under interpretation 1.A this is possible (without the explicit
 > xlink:type='resource' attributes), but not under interpretation
 > 1.B or interpretation 2.
 >
 > Questions:
 > - Can these quotes be reconciled?
 > - Which interpretation is correct?
 > - Am I missing something obvious?
 >
 > Reference:
 >
 > [Spec]: XLink draft spec (2000-12-20), http://www.w3.org/TR/xlink/
 >
 > Thanks.
 >
 > David Jackson

I hope this helps...

         Eve
--
Eve Maler                                             +1 781 442 3190
Sun Microsystems XML Technology Development  eve.maler @ east.sun.com