Re: DOCBOOK: Linking in DocBook (specifically for EBNF, but more generally as well)

[Terry Allen <tallen at sonic dot net>]

Eve wrote:
| 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.

Sigh.  I see I missed this rev of Xpointer.  Downloading it, I see it's 
large spec the very first paragraph of which sets my teeth on edge with
its prescriptiveness (I wish the W3C would lose the idea that it's
creating The Single XML Application).  Anyway, what is its relation to 
Xlink?

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

"#foo" doesn't seem like a shortcut to me, as it's relative-URL
syntax.  So now I'm worried.  Can you tell me where in the Xpointer 
spec the proposed syntax is defined?

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

Considering Xpath's use of non-XML syntax, I'm not sure that reassures 
me that something else won't come along.  But to stick to the point, has 
Xpath been implemented, and how completely?  (That is, how do we know
it solves its problem completely?)

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

In HTML variants, is it required that NAME atts have values unique
within the instance (I haven't kept up with XHTML; the HTML 4.0
DTD doesn't require it)?  (That is, how close to ID/IDREF are we
getting?)
...

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

It would seem we're close; it's unfortunate we can't wait longer
for the present purpose.

| 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 

Yep.

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

Jon mentioned RELAX to me, but otherwise I've not heard of it.

What worries me here is that we're dipping our toe into the linking
problem without considering a thoroughgoing change across the DTD, and
without tool support.  We were more conservative in the past.

I can see that for linking to nonterminal definitions there should be 
only one target to point at, so it would seem safe to go the Xpointer
route; would we use the same approach to convert all present
ID/IDREF (not ID/IDREFS) links?

On second thought, maybe I'd prefer two attributes, too.

regards, Terry