[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