Re: DOCBOOK: Minutes: DocBook Technical Committee Meeting: 21 Aug 2001

[Daniel Veillard <veillard at redhat dot com>]

On Fri, Aug 24, 2001 at 08:31:39AM -0400, Norman Walsh wrote:
> / Daniel Veillard <veillard@redhat.com> was heard to say:
> | On Thu, Aug 23, 2001 at 02:31:47PM -0400, Norman Walsh wrote:
> | > |    b. Norm to write a concrete proposal for linking in DocBook 5.0
> | 
> |   Hum, assuming DocBook 5.0 is XML only, did you evaluate XLink ? I
> | assume you at least looked at it, and if yes do you have an archive
> | of pros/cons available ? 
> 
> Hi Daniel,
> 
> The TC has backed off it's "XML-only" position, but the solution will
> still be XLink based :-). I don't think any other position would be
> defensible. I'm still sortof waiting to see what happens with
> XPointer, although I recognize that XLink can be used without it.

  Hum, I think I can safely say "don't hold your breath", and that
we can cordially disagree on what would be the best solution in the end :-)

  The only think which sounds safe is that whatever spec is gonna end-up
being the fragment identifier for XML resources, #foo will have to
be mapped to the ID foo if it exists or generate a sub-resource error
otherwise. So keeping adressability based on ID is crucial, and so far
is the only mechanism one can safely recommend (and I really hate I have
to say this !).

> What we need is a concrete proposal that addresses a few specific
> issues.
> 
> 1. Do we add a new linking element for XLink or replace the existing
>    linking elements with XLink equivalents.

  Hum, since linking semantic is only expressed using attributes, can't
you just maintain the old constructs and express their semantic using
defaulted XLink attributes ? 
  It doesn't solve the migration from an ref="foo" to xlink:href="#foo"
but actually alows both and people will see what fits best depending
on their environment and tools.
  Then for more advanced linking mechanism, new elements should be created
if there is user demand for them.

> 2. Assuming the latter, do we just replace the current linking
>    elements with XLink, or do we adopt a more pervasive linking
>    solution.

  IMHO keep the old ones, add defaulted XLink semantic, and new elements
for new linking concepts
  
> 3. Assuming we want to be more pervasive, how pervasive? Should every
>    element carry the XLink attributes so that you can link from anywhere
>    to anywhere? Or just from inlines? Or ...

  Hum, XLink don't requires the resource being used as source or target
to have any specific markup, both simple links and locators will work
with xlink:href="doc#foo", only locator and resources need an xlink:label
but that's contained in the link construct itself not the source or target.
Double check with Eve Maler if you have the opportunity.

> 4. What do we do about OLink which has no XLink equivalent.

  Hum, I would have to look at the construct, but I would say keep it
for backward compatibility.

  Actually the main feature I would really like to see is a way
to manage link bases. Let me explain: 

  In the Gnome project, each module has its own doc. Modules can be installed
or upgraded individually, and basically we need a simple way to make
cross references work in the resulting set of docs. Currently we are running
an horrible but useful script which makes the link resolution at instal-
lation time (very much like any other software linking phase), but this
doesn't scale. What would be really useful is an external linkbase construct
allowing to gather links relationship in a single entity, this would
seriously ease this cross reference mechanism maintenance.

Daniel

-- 
Daniel Veillard      | Red Hat Network http://redhat.com/products/network/
veillard@redhat.com  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>