This is the mail archive of the docbook@lists.oasis-open.org mailing list for the DocBook project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Linking in DocBook V5.0


/ Daniel Veillard <veillard@redhat.com> was heard to say:
| On Wed, Nov 14, 2001 at 11:07:10AM -0500, Norman Walsh wrote:
| > Given a PE like this:
| > 
| > <!ENTITY % xlink-optional-simple-link "
| >    xlink:type      (simple)        #IMPLIED
| [...]
| > The link, xref, and ulink elements would have xlink:type #FIXED to
| > "simple".  (Let's consider OLink separately, the TC is already
| > considering changing it and while it makes sense to align it with
| > XLink, it's important to remember that OLink has semantics that cannot
| > be expressed in XLink.)
| 
|   On one hand, the idea of having all inline elements being capable
| of linking semantic sounds good. But it might get confusing to have
| different kind of linking semantic for a given element. Souldn't 
| role and arcrole have IMPLIED values too (and their semantic defined
| too) ?

I left xlink:role and xlink:arcrole implied in my proposal. I'm not
sure what confusion you're thinking of. Is it related to olink, to the
other linking elements, or to using xlink for inlines, or some
combination of those?

| > For extended links, I'm not sure what makes the most sense. We could
| > add new elements, extendedlink, linktitle, linkresource, linklocator,
| > and linkarc. Or we could say that extended links must be out-of-line.
| > Or perhaps we could do something else. Suggestions?
| 
|   I don't know DocBook well enough to suggest anything here :-)
| One of the clear use case I have and would like to be able to use is
| external link base usable for indexes of document collections, so
| please don't rule out extended links.

For external link bases, you always have the option of making them
entirely separate documents; they don't even have to be in your
DocBook document. The question really is, do you need or want to be able
to say:

  <chapter>
   <chapterinfo>
     <extendedlink>
      <locator .../>
      <locator .../>
      <arc ../>
     </extendedlink>
   </chapterinfo>
   ...

Unless someone implements the linking and style note's infoset
normalization of linking semantics, I don't even know how a stylesheet
would deal with these.

| > I'm definitely opposed to mandating XPointer before it's a REC. I
| > guess we might need to add a 'pointing vocabulary' identifier
| > somewhere,
| 
|    I think that mandating 
|       #foo
| to go to the element of ID "foo", is a first step, compatible with
| XPointer.

Yes. If we go the pointerlanguage route, we could, for example, let it
be a URI. Given

  pointerlanguage='http://www.oasis-open.org/docbook/...'

we could say that the only legal form is #id or a full URI reference.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com>      | The irrational is not necessarily
http://www.oasis-open.org/docbook/ | unreasonable.--Sir Lewis Namier
Chair, DocBook Technical Committee |

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]