This is the mail archive of the docbook@lists.oasis-open.org mailing list for the DocBook project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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


On Fri, Aug 24, 2001 at 10:01:46AM -0400, Norman Walsh wrote:
> |   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"/>

  yes, I know ... one would need to add a little bit of extra logic
in the tools.

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

  I'm not sure we understand each-other. I'm just saying that 
    <xref xlink:href="#bar"/>
just requires ID support on the target element, not XLink specific constructs.
Now you may still want to be able to make simple links starting from any
elements, then yes you will have to be pervasive :-)


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

  Two versions before it got published, but not the latest one :-)

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

  I suppose I will have to re-read section 3.2 to make an estimation of the
pain required to support the new constructs :-) (and allocate the time
for it which would be far more of a challenge :-\).

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>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]