/ Peter Eisentraut <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> | 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
