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

[Norman Walsh <ndw at nwalsh dot com>]

/ Daniel Veillard <veillard@redhat.com> was heard to say:
|   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 :-)

:-)

| > 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 ?

To a certain extent.

|   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.

Ugh: <xref linkend="foo" xlink:href="#bar"/>

| > 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

Well, that has a certain appeal, but there's been a fair amount of
pressure to allow much more ubiquitous linking. Some people want to
link <command> back to a refentry, <methodname> to a class definition,
<author> to a personal web page, etc.

| > 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.

Relying on external links to handle what appear to be straightforward
links from A to B in the same document is (1) setting the tools bar
pretty high and (2) setting the authoring bar pretty high.

| > 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.

Yep. I think that's the answer.

|   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.

Indeed. Have you read http://www.w3.org/TR/xml-link-style/

Maybe we could cooperate and produce an implementation that works in
(some Java processor) and xsltproc? :-)

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com>      | As a general rule, the most
http://www.oasis-open.org/docbook/ | successful man in life is the man
Chair, DocBook Technical Committee | who has the best
                                   | information.--Benjamin Disraeli

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