Proposal 13120: Vocabulary for Cross-Deliverable Linking Processing

[Eliot Kimber <ekimber@rsicms.com>]

I have posted the Stage 2 proposal for 13120, vocabulary for supporting
cross-deliverable link processing.

The proposal defines a new metadata domain, deliverableMetadataDomain, a new
topic type, deliverableDefinition, and a new map type,
deliverableAsDeliveredKeydefSet.

Together these provide the markup needed to communicate processing details
among otherwise uncoordinated deliverable-producing processors so that they
can produce deliverables with working cross-deliverable links.

One implementation detail that I hadn't really fully appreciated or
articulated before is the requirement, in the general case, to generate key
definitions for each element within a topic that has an ID when the topic
has an associated key. This is because for each *reference* to an element
within a topic, the key/id pair has to be replaced with a single key, since
the reference now has to result in a direct URI reference to the target
element, not just the target topic. Because in the general case you can't
predict which elements somebody might want to link to from another
deliverable, you have to generate keys for all of them. Note that topics for
which there are no associated keys can safely be ignored because
cross-deliverable links can only be done with keys.

This could result in a large number of key definitions in the as-delivered
key definition set map. It also emphasizes the importance of only putting
IDs on those things you actually want people to be able to link to, rather
than on element element of a certain type or every element that could have
an ID.

Of course, in a specific implementation, the processor could do things to
minimize the number of generated key definitions, including only generating
definitions for specific element types, say <fig>, <table>, and <step>, or
only generating definitions for elements actually referenced from some known
set of other documents, or whatever. In the context of CMS system where it
knows what links to what, it could only generate the key definitions
actually required by the documents it manages.

I've created an Open Toolkit plugin that provides the RelaxNG version of the
vocabulary modules and shell document types along with some test documents.
I tested this with OxygenXML V15, although it should work fine with V14.2.
We're still working on the RelaxNG-to-DTD generation process so I'm not yet
able to generate DTD declarations from the RelaxNG, but I should be able to
soon.

Cheers,

Eliot 


-- 
Eliot Kimber
Senior Solutions Architect, RSI Content Solutions
"Bringing Strategy, Content, and Technology Together"
Main: 512.554.9368
www.rsicms.com
www.rsuitecms.com
Book: DITA For Practitioners, from XML Press,
http://xmlpress.net/publications/dita/practitioners-1/