Re: DOCBOOK-APPS: Re: DOCBOOK: Minutes: DocBook TechnicalCommitteeMeeting: 21 Aug 2001

[Jirka Kosek <jirka@kosek.cz>]

Daniel Veillard wrote:
> 
> On Fri, Aug 24, 2001 at 01:35:34PM +0200, Jirka Kosek wrote:
> > There are too many possibilites. As far as merging of DTDs cann't be
> > automated, going DTDs way to support other markup schemes than DocBook
> > in DocBook documents is not long term solution (but may be used if you
> > need MathML or SVG in your document right now). My personal opinion
> > about DocBook future is to let it be single DTD, doing linking and
> > inclusion by DocBook's elements. When there will be more tools
> 
>   Then you're gonna create a legacy problem that you will
> NEVER be able to get rid of. If you start adding DocBook linking
> specific construct, this mean in practice you will never get your
> user base to switch to a more standard solution.

I don't want to add new linking elements to DocBook. Linking in DocBook
is there from start of 90s, XLink is a new standard, I don't think that
every application should switch to XLink from its own linking mechanism.
This is true especially for DocBook - DocBook sources are often
processed to HTML or FO before viewing. IMHO there is no benefit from
using some sort of XLink processor or XML browser with XLink support for
DocBook users.

>   Been there, done that, fighted for 2.5 years with the HTML WG
> at W3C, not fun at all, I don't intend to do the same here, which
> also mean that if you don't want to use XLink I won't make any mess.

XLink has its own place. If I will have a lot of smaller XML document
and want to create links between them, I will use XLink. If I will need
to create external database of anotations I will use XLink or RDF. I
think that XLink is very important especially when we want to display
XML directly to end-users. Without XLink and browser with XLink support
you weren't be able to do linking. For this purpose XLink is good
technology.

But in DocBook you often create in-document links. Yes, you can create
them with XLink and XPointer. But for me it is easier to write:

<xred linkend="chapter3"/>

than

<xref href="#chapter3"/>

and in that case I'm using as much defaulting as is possible. If I want
to blame XLink I would write it as

<xlink:xref xlink:href="#xpointer(id(chapter3))" xmlns:xlink="..."/> 

Current method used in DocBook also has advantage of validation of
links. They are defined as ID/IDREFs and thus are automatically checked
when doing validation. I'm not sure if this is possible with XLink and
current tools.

XLink might bring some new features when creating inter-document links.
But big problem which I see there is not syntax used to create links,
but non-existence of some name resolving mechanism. If you have two
DocBook document and want to create links between them, these links
should look diferrent in HTML and PDF versions of documents. In HTML you
link should target HTML file, in PDF second PDF file. 

Without name resolution mechanism you can effectively create links only
between XML documents and do all rendering on-the-fly. Even there is a
big progress in performance of XSLT (thanks for libxslt;), on-the-fly
approach is not appropriate in all situations.   

>   But you go this way you should clearly state that you don't care
> reusing those standards, that would be more frank.

Reuse is good, but I'm not sure (see above) if DocBook will benefit from
XLink for now and in the near future.
 
					Jirka

-----------------------------------------------------------------
  Jirka Kosek  	                     
  e-mail: jirka@kosek.cz
  http://www.kosek.cz