Link relationships

[Norman Walsh <ndw@nwalsh.com>]

I'm still trying to get my head around the relatedlinks in documents
and relationships in assembly files. If these are two different ways
of expressing the same thing, I want to be able to normalize them down
to a single form for processing.

In the assembly file, a relationship is a collection of elements
identified by xml:id attributes.

  <relationship type="component">
    <instance linkend="db.book"/>
    <instance linkend="db.chapter"/>
    ...
  </relationship>

I think this means that after we've assembled the document, the
collection contains all the elements for which the assembled document
has a corresponding xml:id. I think this also means that the
relationship instances can point to either modules or resources (since
the only thing that really matters is the presence of the xml:id).

If that's right, then an inline relatedlink element should just be
an ID as well:

  <para>There are chapters<relatedlink linkend="db.chapter"/> and
  appendixes<relatedlink linkend="db.appendix"/> in a book.</para>

That feels a little weird, though. Authors might feel that they should
be able to identify the resource and the id. OTOH, the link only has
meaning if the corresponding resource is included, so I'm not sure
that makes a lot of sense either. If the author has four resources
with xml:ids that have the value "db.chapter", is this a related link
to any one of them that might be included in any assembled document,
or is it a link to only one of them. Or is it a link to two of them?

Also, in both cases, it's probably a mistake to name the attributes
"linkend" because they can't have the type IDREF. Maybe targetptr
would be a better name, parallel to olink.

Are any of these observations consistent with other's ideas about
related links and relationships?

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com>      | The shortness of life can neither
http://www.oasis-open.org/docbook/ | dissuade us from its pleasures,
Chair, DocBook Technical Committee | nor console us for its pains.--
                                   | Vauvenargues

PGP signature