OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

docbook message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


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


> From: 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) ?

No, it would not be sufficient.  Link and xref will remain
the primary means for forming links. If you want
to form internal links, use the linkend attribute and let the
processor validate your IDREFs.  But XLink lets you
link outside of the current document, which is a
very powerful new feature.  For those links you
need the xlink attribute, and the processing machinery
has to resolve those links and report errors.
Removing that feature from the primary linking elements
would be a mistake, IMHO.

Not that resolving external links is an easy thing.
I highly recommend Norm's paper "XML Linking and Style"
(http://www.w3.org/TR/xml-link-style/) for an informed
presentation of the difficulties of resolving
external links in styled documents.  

bobs
Bob Stayton                                 400 Encinal Street
Publications Architect                      Santa Cruz, CA  95060
Technical Publications                      voice: (831) 427-7796
Caldera International, Inc.                 fax:   (831) 429-1887
                                            email: bobs@caldera.com


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC