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

At 21:48 2002 06 21 +0000, Norman Walsh wrote:

>2. Use XLink
>   This proposal suggests that we add XLink attributes to some number of
>   inline elements, allowing DocBook users to use markup like the following:
>     The <application xlink:href="http://docbook.sf.net/";>DocBook XSL
>     Stylesheets</application>

If the xlink:type attribute is #IMPLIED as you show below,
then wouldn't you have to include it explicitly on any tag
you wanted to be a link?

So wouldn't the above have to be:

     The <application xlink:type="simple" xlink:href="http://docbook.sf.net/";>DocBook XSL

I think we want to make the xlink:type attribute #FIXED (and
defaulted to 'simple') to avoid this.

>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
>        xlink:href      CDATA           #IMPLIED
>        xlink:role      CDATA           #IMPLIED
>        xlink:arcrole   CDATA           #IMPLIED
>        xlink:title     CDATA           #IMPLIED
>        xlink:show      (new|replace|embed|other|none)  #IMPLIED
>        xlink:actuate   (onLoad|onRequest|other|none)   #IMPLIED
>The xlink prefix would be parameterized in the DTD.
>If the xlink:href attribute is unspecified, linking semantics do not

>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.
>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?

>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.

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?
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?


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

Powered by eList eXpress LLC