OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

docbook message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: DOCBOOK: Re: Proposal: Linking in DocBook

/ Jirka Kosek <jirka@kosek.cz> was heard to say:
| Norman Walsh wrote:
|> In practice, this would mean adding the following attributes to each
|> of these elements:
|>         xmlns:xlink     CDATA           #FIXED 'http://www.w3.org/1999/xlink'
|>         xlink:type      (simple)        #IMPLIED
| This attribute should be rather fixed (#FIXED "simple"). If not, user
| will be forced to add xlink:type="simple" to each instance of some
| linking element.


| Sorry I don't understand what "FU" means. But I suppose that you mean
| removing these attributes.

Sorry, "FU" is short hand for "add a Future Use comment indicating
that these attributes will be removed in the next full-version release
of DocBook".

| I recognize importance of standards and I think that adopting XLink is
| reasonable way. But current proposal will left DocBook in quite
| unnatural state IMHO, where some linking will be made "old way" like
| <xref linkend="foo"/> or <ulink url="bar">...</ulink> while other
| linking will use XLink semantic like <glossterm xlink:href="#foo"/>. I
| think that this will look very odd -- some pointers inside other place
| in document will use just ID, some else will use fragment identifier
| (#ID). This might be very confusing. 

True. Perhaps the subsequent proposals are a bad idea. (That's why I
made them entirely separate.) OTOH, if we add XLink links, the only
way to get complete uniformity again would be to deprecate and remove
all of the "old" linking elements (or at least the old attributes).

| - Not compatible with XLink tools -- this is not problem now, but might
| be in future. At these days DocBook documents are processed by XSLT (or
| other tools) to get HTML, FO, ... During this transformation linking
| semantic is converted from DocBook to target vocabulary. In that case it
| is unimportant whether is linking expressed by XLink or custom DocBook
| attributes. Problems might arise when you want use DocBook source
| directly in some XLink enabled viewer. 

More likely (at least in the short term, I think), are XLink aware
applications that do link management tasks. I can imagine, for
example, a Content Management System that provided an XLink
consistency filter on document checkin.

XLink enabled, XML hypertext viewers capable of directly rendering
DocBook in a meaningful way are probably farther out in the future.

| I would preffer going 3rd way and keep DocBook compact. If we should go
| XLink way, I think that it will be better to change all linking into
| XLink (including e.g. xref, ulink, link) way and keep DocBook
| consistent. Unfortunatelly this change will be backward incompatible,
| but it will be very easy to fix old documents (mostly be replacing
| linkend="..." to xlink:href="#..."). 

I had thought we could do this in stages: adding new linking
constructs in a non-backwards compatible way and then perhaps making
some backwards incompatible changes in the future.

Are you saying that you'd prefer an "all at once" approach, delaying
any linking changes until V6.0, and then simultaneously replacing all
of our linking elements with XLink and adding new linking?

| I don't see good solution for new linking requirements. I just have
| feeling that mixing two linking modes can confuse many users and TC
| should be very carefull in this issue.

I share your concern, but I think this change is reasonably easy to
explain to users.

                                        Be seeing you,

Norman Walsh <ndw@nwalsh.com>      | No victor believes in
http://www.oasis-open.org/docbook/ | chance.--Nietzsche
Chair, DocBook Technical Committee |

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC