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: Linking in DocBook (specifically for EBNF, but more generally as well)

At 01:36 PM 4/7/00 -0700, Terry Allen wrote:
>| <nonterminal xlink:href="#foo">
>1. Is this correct Xlink syntax for a pointer to a single target?
>(I knew shortly after I read the Xlink spec but have forgotten.)

It's correct XPointer syntax for identifying an element with this value for 
its ID-type attribute.

>2. Is Xlink stable in this regard?

The ID functionality is stable because XPath is already a W3C 
Recommendation.  The #foo shortcut is specific to XPointer.  I can't 
promise that it's stable, but XPointer has exited Last Call and will soon 
(I hope) enter its Candidate Recommendation period (sort of a beta period).

>3. Has Xlink been implemented?

In this case, it's XPointer.  The CR period is supposed to determine 
whether the entire spec is implementable; we're anticipating success at 
this, since 95% of XPointer is XPath.  I don't know any (e.g.) browsers 
that support XPointer yet in fragment identifiers on URIs, but that's not 
surprising.  I know of some internal use of the #foo shortcut, where a 
trivial transform is done to turn it into a classic IDREF.

>4. Will "#foo" work like ID/IDREF in current tools?  (I would
>think it wouldn't.)


>I see the need, but I'd like not to get to the party too early.

DocBook has been waiting for linking standards to stabilize for at least 
five years; perhaps we won't have to wait much longer.

We don't have to decide to go the one-attribute route right away, but the 
two-element solution that you suggest seems to be merely an artifact of the 
lack of expressive power in DTDs, and it would be a shame if that were the 
long-term solution.  (By the way...the RELAX schema language allows you to 
define alternative versions of element constraints based on attribute 
values, which would be a neat way out of this design dilemma. :-)  I'd 
rather have two attributes and an extra-DTD constraint than two elements.


Eve Maler                                    +1 781 442 3190
Sun Microsystems XML Technology Center    elm @ east.sun.com

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

Powered by eList eXpress LLC