Re: DOCBOOK: Linking in DocBook V5.0

[Daniel Veillard <veillard at redhat dot com>]

On Wed, Nov 14, 2001 at 11:07:10AM -0500, Norman Walsh wrote:
> 2. Allow *all* elements to function as XLink simple links.
> 
> 3. Allow some elements to function as XLink simple links.

  2 or 3 seems resonable to me

> So my proposal is that we allow most (all?) inline elements to
> optionally function as simple links. We may also want to allow
> selected other elements (like funcprototype) to function as simple
> links as well.
> 
> Given a PE like this:
> 
> <!ENTITY % xlink-optional-simple-link "
>    xlink:type      (simple)        #IMPLIED
[...]
> The link, xref, and ulink elements would have xlink:type #FIXED to
> "simple".  (Let's consider OLink separately, the TC is already
> considering changing it and while it makes sense to align it with
> XLink, it's important to remember that OLink has semantics that cannot
> be expressed in XLink.)

  On one hand, the idea of having all inline elements being capable
of linking semantic sounds good. But it might get confusing to have
different kind of linking semantic for a given element. Souldn't 
role and arcrole have IMPLIED values too (and their semantic defined
too) ?
  It also make sense to let people apply a different semantic, or
even a different kind of link (for example associating external
linkbase to <person>).

> One outstanding problem is the link attribute names. Unfortunately,
> XLink doesn't allow the XLink HREF attribute to be renamed, so we'll
> have to battle the linkend vs xlink:href problem. I think we have
> two options, we could:
> 
> 1. Switch. Remove linkend and break everything all at once.
> 
> or
> 
> 2. Allow both in V5 and remove linkend in V6. Stipulating that when both
>    are present linkend wins (or xlink:href wins, whichever).
> 
> I'm pretty solidly on the fence at the moment.

  The XLink push is already a large change, allowing a grace period
sounds a good idea to me (though the HTML name="" to id="" is a bad
precedent to look at, but I expect DocBook users/toolchains to be 
better than their HTML counterpart <grin/>).

> For extended links, I'm not sure what makes the most sense. We could
> add new elements, extendedlink, linktitle, linkresource, linklocator,
> and linkarc. Or we could say that extended links must be out-of-line.
> Or perhaps we could do something else. Suggestions?

  I don't know DocBook well enough to suggest anything here :-)
One of the clear use case I have and would like to be able to use is
external link base usable for indexes of document collections, so
please don't rule out extended links.

> Finally, there's the issue of what pointing language our links use.
> XLink does not normatively reference XPointer and XPointer is not a
> Recommendation anyway. I'm inclined to be explicitly silent on this
> point and add it to the interoperability checklist.
> 
> I'm definitely opposed to mandating XPointer before it's a REC. I
> guess we might need to add a 'pointing vocabulary' identifier
> somewhere,

   I think that mandating 
      #foo
to go to the element of ID "foo", is a first step, compatible with
XPointer.

Daniel

-- 
Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard@redhat.com  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>