> From: Elliotte Rusty Harold <[EMAIL PROTECTED]> > > >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 block elements as click text in HTML or a cross reference in print. I'm not saying it can't be done with some thought and design, but it isn't obvious. On the other hand, I appreciate your desire to get out of the restraining box of current rendering environments like HTML. There are all kinds of other possibilities for processing DocBook XML documents, such as help systems and indexing. Permitting xlink on larger elements opens up capabilities beyond the current simple linking done today. But if it is permitted, I think we have to make clear what the processing expectations are. We could say that xlinks in block elements are permitted but not currently handled by Norm's DocBook html and fo stylesheets. But the markup can be added to XML files for other purposes and processing of your own design. This is similar to the way role attributes are handled today. If some common usage emerges, then perhaps those specific changes can be added to Norm's stylesheets. bobs Bob Stayton 400 Encinal Street Publications Architect Santa Cruz, CA 95060 Technical Publications voice: (831) 427-7796 Caldera International, Inc. fax: (831) 429-1887 email: [EMAIL PROTECTED] ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>