[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: DOCBOOK: Re: [docbook-tc] Proposal: Linking in DocBook
/ Peter Eisentraut <peter_e@gmx.net> was heard to say: | Norman Walsh writes: | |> Fork 2: Do It Our Way OR Do It the XLink Way |> |> If we do it our way, we get to define the semantics, but no tool will |> ever support our linking elements directly. (Well, I suppose some |> special purpose DocBook tool might, but let's not worry about that.) | | I'm wondering how such "direct" support would look like. All toolsets | that work with DocBook are in some way specially purposed for DocBook. That's just not true. I have tools that work with any well-formed XML document. Some of them do fairly trivial things, like count words and scramble #PCDATA, but they don't care what markup is used. The advantage of XLink here is that I could write similar tools for doing link analysis or harvesting and they would work with any vocabulary that used XLink for linking semantics. | Today we have XSLT and DSSSL stylesheets (and other obscure conversion | tools) that work specially with DocBook. Even in the unforeseeable future | there will have to be some sort of tool that associates semantics to raw | DocBook. For presentation, yes, but not for linking if the world adopts standardized linking markup. Similarly, if the world adopts SVG and/or MathML, you could write schema-agnostic tools to extract drawings or equations from XML documents. | For such a tool it's pretty irrelevant whether it converts xlink | or some other linking system for presentation. True. Be seeing you, norm -- Norman Walsh <ndw@nwalsh.com> | Abandoning rhyme and fixed rules http://www.oasis-open.org/docbook/ | in favor of other intuitive rules Chair, DocBook Technical Committee | brings us back to fixed rules and | to rhyme with renewed | respect.--Jean Cocteau
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC