[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 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC