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: DOCBOOK: Re: Linking in DocBook V5.0


/ Bob Stayton <bobs@caldera.com> was heard to say:
| > From: Elliotte Rusty Harold <elharo@metalab.unc.edu>
| > 
| > >Yes, that's one of the factors that motivates me as well. We'll have
| > >enough trouble with nested inlines. (And, btw, my gut reaction is to
| > >generate broken HTML. The browser ought to handle nested links, gosh
| > >darn it. Oh, I know I'll get talked out of it, but that's still my gut
| > >reaction.)
| > 
| > Yes, but this disadvantage applies equally well to nested inlines as 
| > you point out. If this really bothers us, we shouldn't add XLinks at 
| > all. I don't think this is an adequate reason to disallow XLinks on 
| > block level elements.
| 
| Norm's concern comes from his having to write
| stylesheets to render whatever is permitted in
| DocBook.  It isn't clear to me how one renders

Pragmatically, that's certainly a concern that I have, but even
looking at the issues independent of the additional burden for
stylesheet authors, I have concerns.

Adding linking *everywhere* would in many ways be a radical departure
from both historical legacy in DocBook and current practice "in the
field". There are no environments that I'm aware of where users can
routinely associate links with absolutely any semantic element they
choose.

When I consider that departure, I'm struck two big things and a few
little things:

1. "Man, that's a big step."
   a. If we go there, it will take two full revisions of DocBook (V 7.0) to
      get back. That's a pretty significant commitment.
   b. You know, we don't actually have to cross this chasm in one step. There's
      a pedestal half way across that we could stand on. We could add linking
      to a lot of inline elements (which we already have some experience with
      and which users have lots of experience with) and see how it goes.

2. If you have a processing environment that's sophisticated enough to
   handle totally arbitrary linking, you're working with some powerful tools.
   a. Couldn't you make extended links work in that environment and
      keep the links from big blocks in extended links.
   b. If your application really demonstrates the usefulness of these links,
      we can always add them later.
   c. If b but not(a), then you can add them as an extension and show the
      world directly how useful it would be to have them in the standard
      distribution.

Another advantage to waiting a while is that XSLT 2.0 will have some
facilities that make untangling nested links a much more tractable
problem. DSSSL, alas, probably never will. (I'm thinking here of
result tree fragments, where you can query and manipulate the results
of previous transformations.)

| We could say that xlinks in block elements are
| permitted but not currently handled by Norm's
| DocBook html and fo stylesheets.

I want to say just a word or two here. I think we have to keep in mind
that my stylesheets are not in any way a normative committee work
product. While I appreciate that they are widely used, and certainly
my own opinions are often shaped by my experiences implementing
features in them, just because they don't handle a particular feature
is not in and of itself a strike against the feature.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com>      | The great man is he who has not
http://www.oasis-open.org/docbook/ | lost the heart of a child.--Mencius
Chair, DocBook Technical Committee |


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


Powered by eList eXpress LLC