This is the mail archive of the
docbook@lists.oasis-open.org
mailing list for the DocBook project.
Re: [docbook-tc] Proposal: Linking in DocBook
- From: Norman Walsh <ndw at nwalsh dot com>
- To: Paul Grosso <pgrosso at arbortext dot com>
- Cc: docbook at lists dot oasis-open dot org
- Date: Mon, 24 Jun 2002 08:40:47 -0400
- Subject: DOCBOOK: Re: [docbook-tc] Proposal: Linking in DocBook
- References: <4.3.2.7.2.20020621161652.03a99718@172.27.10.30>
/ 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
well.
|> 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
it).
|>If the
|>xlink:role URI is anything else, the semantics are implementation
|>defined.
|
| 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
elements.
| 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,
norm
[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