This is the mail archive of the
docbook@lists.oasis-open.org
mailing list for the DocBook project.
Re: Linking in DocBook (specifically for EBNF, but more generally as well)
- To: docbook at lists dot oasis-open dot org
- Subject: Re: DOCBOOK: Linking in DocBook (specifically for EBNF, but more generally as well)
- From: Terry Allen <tallen at sonic dot net>
- Date: Sun, 9 Apr 2000 10:22:43 -0700
- Reply-To: docbook at lists dot oasis-open dot org
Norm wrote:
| / Terry Allen <tallen@sonic.net> was heard to say:
| | 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?)
|
| Given the number of XSLT processors available, I think it's safe
| to say that XPath has been implemented several times.
Okay.
| | | 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?)
|
| Keep in mind that fragment identifiers for HTML (an SGML
| application) and XML are different. The #foo and id('foo')
| XPointer components, when pointing into an XML document, point
| to IDs (i.e., XML ID-valued attributes), not NAME atts on any
| specific element.
Good. I expect confusion will arise in pointing from XML to
SGML, and we might begin to get skew between SGML and XML
instances, but if #foo points to an ID I'm happy.
| | It would seem we're close; it's unfortunate we can't wait longer
| | for the present purpose.
|
| No one said we can't, exactly. At most, I've said I'd like not
| to have to. :-)
|
| | 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.
|
| Good point. To play devils advocate, I'll point out that we're
| discussing this problem in the context of an element with such
| extensive processing expectations that tools support would be an
| issue even without the linking question.
Yes, good point.
| But the fact that '#foo' won't work in existing tools, even for
| ID/IDREF-type links, is a cause for much concern...
|
| | 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?
|
| I'm certainly not proposing that yet. Not before widespread
| tools support, anyway. As you said, we've waited five years to
| address the general linking issues, I think we can wait a couple
| more.
Let's put on the agenda for Paris the question whether we'd
be willing to convert ID/IDREFs to xlink: if we had tools support
(maybe the answer is short; it would be a place to get started
on XML linking).
regads, Terry