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)


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



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


Powered by eList eXpress LLC