Re: DOCBOOK: Re: Linking in DocBook V5.0

[Yann Dirson <ydirson@fr.alcove.com>]

On Thu, Nov 15, 2001 at 02:58:45PM +0100, Jirka Kosek wrote:
> Yann Dirson wrote:
> 
> > 2. "xlink:href" is, well, much less sexy than "linkend", and the name
> > does not really reflect the semantics attached to the attribute as
> > much as "linkend" does - and my guess is that "href" originates from
> > HTML, and that W3C decided not break compatibility in XHTML, right ?
> > Although it's cool for XHTML authors, I'm sure it would be as cool for
> > DocBook authors not to have compatibility broken either.
> 
> There is another issue with using xlink:href compared to linkend.
> linkend attribute is of IDREF type. So if you want to check consistency
> of your inter-document links, you just run validation on your document.
> Some XML editors are even capable to provide you with a list of already
> defined IDs when you are inserting new link.

...and consequentely "linkend" cannot be architecturally mapped to
xlink:href, so my suggestion to use an AF is ruled out.  Good point.


> <xref xlink:href="#some_id_in_doc"/>
> 
> This link can't be checked by validation, you must check it when
> processing document by stylesheet or some clever XLink processor (if
> there is any). 

Or does Xpointer or XLink attach strong IDREF-like semantics to these
"href"s ?  Or if not would it be possible that an evolution of those
would do so ?


> Considering validation and comfortable editing issues I'm not sure
> whether removing linkend in future is wise. But having two attributes
> (linkend, xlink:href) for doing almost same in parallel brings many
> troubles and uncertainity in processing as Norm pointed earlier.

Wild thought: would it be sufficient to keep the IDREF-based mechanism
for current linking elements (Link/XRef), maybe depreciate ULink, and
add XLink support only to elements other than Link/XRef (which
may not need XLink anyway) ?

[maybe I missed other elements in addition to Link and XRef]

That would address the most of compatibility problem, as well the
validation one.

-- 
Yann Dirson <Yann.Dirson@fr.alcove.com>                 http://www.alcove.com/
Free-Software Engineer				      Ingénieur Logiciel-Libre
Free-Software time manager    	       Responsable du temps Informatique-Libre
Debian GNU/Linux developper <dirson@debian.org>