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

["Eve L. Maler" <Eve dot Maler at east dot sun dot com>]

At 03:53 PM 4/7/00 -0700, Terry Allen wrote:
>Sigh.  I see I missed this rev of Xpointer.  Downloading it, I see it's
>large spec

It's got a huge non-normative appendix describing XPath, which I would like 
to rip out, but so far I haven't had the votes.  But since it's layered on 
XPath, feel free to consider it huge anyway. :-)

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

The prescriptive nature of XPointer (being the official fragment identifier 
syntax) is precisely its reason for being; this spec will eventually be 
referenced by the XML Media Types registration documents as the official 
way to refer to XML fragments.  In earlier versions, we overreached and 
tried to change some of the URI infrastructure as well, but we were 
properly slapped down. :-)

>Anyway, what is its relation to
>Xlink?

XLink is an XML vocabulary that allows XML documents to contain 
"standardized" linking markup.  It can be useful if recognized as-is by 
browsers, but a lot of the time it is likely to be used in the formulation 
of a higher-level language that has some linking in it.  You can think of 
it, inaccurately, as letting XML documents "link to" other things.  (It's 
inaccurate because some XLink links don't link the document they're in to 
something else; they link remote things together.)  XLink links can 
associate non-XML resources, even though the linking elements themselves 
are always in an XML document.

XPointer is a non-XML mini-language that gets used as fragment identifiers 
on URIs, when the URI refers to something with an XML (text/xml or 
application/xml) media type.  It is specifically designed to be extensible 
and useful for other XML-based media types if they want to use it in 
defining their own fragment ID languages.  XPointers can appear in non-XML 
resources (e.g., HTML), even though they always address into an XML document.

We're hoping to start a public Linking website soon, and a FAQ is 
definitely in order!

>"#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?

Actually, it's not related to whether a URL is relative.  Here's how things 
break down:

URI           :== URL (either relative or absolute) or URN.
fragment ID   :== # followed by stuff, with syntax specific to the thing
                   pointed to.
URI reference :== URI part and fragment ID part, both optional as long
                   as one is present.

If you want to eliminate fragment IDs from appearing, you say "URI".  If 
you allow fragment IDs and don't say anything about eliminating relative 
URIs, then you're allowed to have, e.g., both ../foo#bar and 
http://www.example.com/foo#bar formulations.

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

XPath was designed to be used, first and foremost, inside XML attributes, 
where XML syntax would be extremely annoying to deploy.  I suppose that an 
XML binding could be invented for XPath, but so far no one has seen the 
need yet.  I think the XML Query group has been talking about requiring an 
XML binding, but may also have a non-XML binding.

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

As I think Norm has pointed out, the HTML #foo and the XPointer #foo aren't 
exactly alike.  (This is actually discussed a bit in the spec itself.)  But 
#foo in XPointer is exactly identical to IDREF.

         Eve

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