[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: DOCBOOK: Proposal: Linking in DocBook
Norman Walsh wrote: > How Would It Work? > ------------------ > > 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. > Related Work > ------------ > > I propose separately that we create a role URI: > http://www.oasis-open.org/docbook/linkroles/moreinfo and specify that > a xlink:href attribute with that xlink:role has the same semantics as > the DocBook moreinfo attribute. Simultaneously, we FU the moreinfo > attribute for V6.0. > I propose separately that we create a role URI: > http://www.oasis-open.org/docbook/linkroles/glossterm and specify that > a xlink:href attribute with that xlink:role has the same semantics as > the DocBook linkend attribute on glossterm and firstterm. > Simultaneously, we FU the linkend attribute on glossterm and firstterm > for V6.0. > > I propose separately that we create a role URI: > http://www.oasis-open.org/docbook/linkroles/ebnf and specify that > a xlink:href attribute with that xlink:role has the same semantics as > the DocBook linkend attribute on constraint and productionrecap. > Simultaneously, we FU the linkend attribute on constraint and productionrecap > for V6.0. Sorry I don't understand what "FU" means. But I suppose that you mean removing these attributes. 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. From this point of view going by 3rd way (doing it ourself) might result in more consistent markup. I see 2 disadvantages in this approach: - 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. If you want gain maximum functionality in this scenario you should indeed use XLink also for xref and other elements to expose all linking information to viewing application. - If we want to allow linking to inside and also outside of document, custom linking attribute should use URI syntax or there should be two attributes (e.g. url and linkend) for outer and inner links. 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 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. Jirka -- ----------------------------------------------------------------- Jirka Kosek e-mail: jirka@kosek.cz http://www.kosek.cz
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC