[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: DOCBOOK: Minutes: DocBook Technical Committee Meeting: 21 Aug 2001
/ 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC