Re: XLink resource confusion (long)

[jackson <jackson@dstc.edu.au>]

Eve

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

Yes, this is clear. It is also a problem.

The spec says (http://www.w3.org/TR/xlink/#simple-links):

"The purpose of a simple link is to be a convenient shorthand
for the equivalent extended link."

However, by the reasoning you have given above (which i
believe reflects the spec), this is not possible. There is no
"equivalent extended link".

Consider this example:

Example 1.a:  Simple link
--------------------------

<section id="sec1"
              xlink:type="simple"
              xlink:href="http://www.someplace.org/something.html">
  <title>Que se yo?</title>
  <par>
      No hay nada de interes en este parafo.
  </par>
  <list>
     <item>Nada</item>
     <item>Aun menos</item>
  </list>
  <!-- Lots more 'par', 'list', 'table', 'figure' elements etc. -->
  <par>
      Esto es aburrido. Y ademas, faltan los acentos.
  </par>
</section>

This is a simple link. It has:
- One remote resource. The location of the remote resource is
given by the xlink:href attribute.
- One local resource. The 'section' element and all its contents.

Example 1.b: Extended link
----------------------------
Convert this to an extended link by adding a locator as a child
of  'section' and changing xlink:type of 'section' to 'extended'.

<section id="sec1"
              xlink:type="extended">
  <loc xlink:type="locator"
          xlink:href="http://www.someplace.org/something.html"/>
  <title>Que se yo?</title>
  <par>
      No hay nada de interes en este parafo.
  </par>
  <list>
     <item>Nada</item>
     <item>Aun menos</item>
  </list>
  <!-- Lots more 'par', 'list', 'table', 'figure' elements etc. -->
  <par>
      Esto es aburrido. Y ademas, faltan los acentos.
  </par>
</section>

Easy. But not equivalent to the simple link from which it was
derived.

The simple link has:
- One remote resource - location indicated by the xlink:href attribute
of 'section'.
- One local resource - itself. That is, the whole of 'section', including
its attributes and all of its contents.

The extended link has:
- One remote resource indicated by the locator 'loc'.
- No local resource at all. (At least as i read it.)

This is not only not equivalent to the simple link in Example 1.a,
it is also of  doubtful utility.

So, what do we do?

Example 1.c:  Extended link with 'resource' elements
-------------------------------------------------
We can add xlink:type='resource' to the contents of the extended link.

<section id="sec1"
              xlink:type="extended">
  <loc xlink:type="locator"
          xlink:href="http://www.someplace.org/something.html"/>
  <title xlink:type="resource">Que se yo?</title>
  <par xlink:type="resource">
      No hay nada de interes en este parafo.
  </par>
  <list xlink:type="resource">
     <item>Nada</item>
     <item>Aun menos</item>
  </list>
  <!-- Lots more 'par', 'list', 'table', 'figure' elements etc.
          All these also have to have xlink:type="resource".
  -->
  <par xlink:type="resource">>
      Esto es aburrido. Y ademas, faltan los acentos.
  </par>
</section>

[Note:
Arcs are not shown for reasons of clarity. They are not the issue
here and would clutter without aiding understanding. I'm also
leaving out other non-essentials such as xlink-defined titles.]

However, this is still not equivalent to the simple link in
Example 1.a.

The extended link now has:
- One remote resource indicated by the locator 'loc'.
- Four local resources specified (plus however many more
'par', 'list' etc. elements there are in the 'section').
 Note also:
    - None of them correspond to the local resource in Example 1.a.
    - The linking element ('section') is no longer a resource, which
       means we 'lose' its name and attributes.

This is not the same as Example 1.a. It is not what i want, nor
is it something that i am likely to want.

What i want is what i've got in the simple link in Example 1.a,
namely one local resource taken as a whole, which is
conveniently divided up into paragraphs, lists, tables, and
so on according to its own purpose, not the purpose of the
link.

Dividing this resource into its constituent parts should be for
me to do or not as i see fit (or of course, a particular application).
It is not something that i want XLink to do for me, or to force me
to do.

It is also a pain to have to add all those 'resource' attributes,
especially since they don't do what i really want anyway.

I don't think it's particularly eccentric of me to want to link my
'section' element as it is to another (remote) resource. This is a
useful thing to be able to do. Others may disagree, but i think it
would be more useful in this case and in many others than what
i have in Example 1.b or Example 1.c.

So, i could use simple links in cases like this. However, what do
i do if i need to use an extended link because i've got TWO remote
resources i want to link?

Example 1.d: Extended link, no local resources
-----------------------------------------------
I could use an extended link with no local resources.

<!-- Somewhere in the same document. -->
<ref xlink:type="extended">
  <loc xlink:type="locator"
          xlink:href="#sec1"/>
  <loc xlink:type="locator"
          xlink:href="http://www.someplace.org/something.html"/>
  <!-- Other locators to remote resources not shown for
          clarity and simplicity. -->
</ref>

<!-- Somewhere else in the same document -->
<section id="sec1">
  <title>Que se yo?</title>
  <par>
      No hay nada de interes en este parafo.
  </par>
  <list>
     <item>Nada</item>
     <item>Aun menos</item>
  </list>
  <!-- Lots more 'par', 'list', 'table', 'figure' elements etc. -->
  <par>
      Esto es aburrido. Y ademas, faltan los acentos.
  </par>
</section>

This is better, but still not what i had with the simple link:
- The previous remote resource is still a remote resource.
- The previous local resource is now a remote resource.

[Note:
The previous link element (Example 1.a) is no longer a
link element. This is not a bad thing in itself- just so we are
clear.]

In many cases this could be a useful alternative. However:
- Dissociated (if i may use this term) extended links are more
complex to deal with.
- I may not want to create extended links which have nothing
to do with the material and serve only to link. They are more
intrusive on document structure than simple links, and possibly
even extended links which are not dissociated in this way.

I should be able to move between simple and extended links
without a radical change in meaning and use when everything
else is the same. After all, the meaning and use of the document
is more important than the meaning imposed by the link, and
should not be interfered with by the link, if at all possible.

So, what i want is to be able to have the simple link nature
(the link element and its content are the local resource) with
extended links (with adjustments so that locators are excluded).

OTOH, being able to have multiple local resources enclosed in
an extended link can also be useful. We do want the ability to
group related but distinct local resources in links.

Nevertheless, i think this may be a less common requirement
than having a "whole resource" which we want to preserve as
such.

Of course, what i think i'd use more often may not be right for others.

> > - Is this optional? Do we get to choose?
> 
> Nope.

Well, actually, i didn't really think we had a choice here.
(Note to self - Forget the irony, unless you're prepared to
use smilies.)

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

There is no xlink:type='title' in my example. The 'title' element
is the title of the paragraph, not the link.

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

Could be done but may be inconvenient. See comments on
Example 1.d.

> If you're only interested in the text content of
> an element, your traversal/rendering process would surely take 
> that into account.

No, i don't want to mix link structure and traversal/rendering in
any way if i can avoid it. I don't think it's a good idea to rely on
some expected processing to make up for inadequacies in link
structure. Similarly, link structure should constrain link use as
little as possible.

> (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.")

Ah! Thanks for that. I wondered what the default was. It's probably
mentioned in the spec, but i'm a bit spec-blind now.

As i mentioned above, i'm ignoring arcs here in order to avoid
clutter in the examples and discussion.

> 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. :-)

Not stupid. Possibly inconvenient.

The ability to do these kinds of tricks adds a great deal of
flexibility to XLink, and i think a lot of us will be resorting to
them some time or other.

> I hope this helps...
> 
>         Eve

Yes, but not there yet.

David Jackson