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: [docbook-tc] Proposal: Linking in DocBook

/ Paul Grosso <pgrosso@arbortext.com> was heard to say:
| I think we want to make the xlink:type attribute #FIXED (and
| defaulted to 'simple') to avoid this.

Yes, you're right. On reflection, I think this makes more sense:

|>        xmlns:xlink     CDATA           #FIXED 'http://www.w3.org/1999/xlink'
|>        xlink:type      CDATA           #FIXED "simple"

#FIXED to "simple"

|>        xlink:href      CDATA           #IMPLIED
|>        xlink:role      CDATA           #IMPLIED
|>        xlink:arcrole   CDATA           #IMPLIED
|>        xlink:title     CDATA           #IMPLIED
|>        xlink:show      (new|replace)   #IMPLIED

I removed 'embed', 'other', and 'none'. I'm tempted to remove 'new' as

|>        xlink:actuate   CDATA           #FIXED "onRequest"

#FIXED to "onRequest".

|>I propose that we create a role URI: http://www.oasis-open.org/docbook/linkroles/ulink
|>If the xlink:role attribute is not specified, the implied value is this URI.

Someone suggested in private mail that we should use URNs. I'm game :-)

|>If the xlink:role URI is http://www.oasis-open.org/docbook/linkroles/ulink,
|>either explicitly or implicitly, the semantics of the link are the
|>same as the semantics of ulink (where url=xlink:href). 
| Then does that mean that the values of xlink:show and xlink:actuate
| are ignored in this case?

With the limitations above, I don't think it matters. We can support
new/replace in HTML, I don't know about FO (I haven't thought about

|>If the
|>xlink:role URI is anything else, the semantics are implementation
| While it may make sense as you've described, it may make sense to
| consider a simplification.  That is, if our requirements are basically
| to provide "ulink-y like linking on other elements", we could simplify
| support for this by just FIXing xlink:show to replace, xlink:actuate
| to onRequest, xlink:role to "the ulink role", and I'm not sure we
| need arcrole at all.

If you look at the bottom of my proposal mail[1], you'll see that I
had some proposals for alternate link semantics. All ulink-y, granted,
but with some additional semantics.

| Another question that comes to mind is what you propose to do about
| the existing link elements such as ulink.  Are we going to add these
| attributes so that it has both an href and an xlink:href attribute?

I propose that we do not add xlink attributes to the existing linking

| Or are we going to leave them as is?  If the latter, then how can we
| argue that our secondary linking elements need arcrole, show, actuate,
| etc. when our primary linking elements don't?

The argument usually runs the other way. At least the equivalent of
'xlink:show' has been requested more than once (for ulink, at least).

                                        Be seeing you,

[1] http://lists.oasis-open.org/archives/docbook/200206/msg00111.html

Norman Walsh <ndw@nwalsh.com>      | The universe that we observe has
http://www.oasis-open.org/docbook/ | precisely the properties we should
Chair, DocBook Technical Committee | expect if there is, at bottom, no
                                   | design, no purpose, no evil and no
                                   | good, nothing but pitiless
                                   | indifference.--Richard Dawkins

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

Powered by eList eXpress LLC