OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

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

Subject: RE: [dita] Groups - Proposal 13120 (HTML) uploaded

Hi Eliot


Had a quick read through.  I applaud this proposal as it closes the loop on the cross deliverable use case and gives the community an interoperable standard for the deliverable export information.


I capture the following essence of your two proposals 13120 and 13041 as the following.  In fact, the two proposals are and should be joined at the hip since the same use cases drive both of them.


I will take a stab at capturing the essence of both proposals – helps me and who knows might help advance the discussion.



1. There is a need for one publication, for example PubB to link to another publication PubA.

2. Two forms a publication exist: The “source content” of the publication which is mostly DITA and used by authors to build the second form, the “deliverable”.  A deliverable is the output of a processor in a particular format such as HTML, PDF or ePub.

3. DITA has an addressing scheme within the source content that supports unique addressing - see addressing discussions regarding filename#topicId/elementId and such forms...

4. It is anticipated that deliverables will also have an addressing and address resolution scheme that supports unique addressing.  However, although deliverable addressing has to retain the semantics of the source content addressing, the actual address values may be completely different.  In other words there is no requirement for a processor to use the exact values, such as XML id attributes, used in source content addresses, in the corresponding deliverable addresses.  For example, a deliverable such as PDF may assign its own unique ids for the purpose of identifying topics in a PDF and in fact this is required because DITA does not require that topic ids be unique across topics whereas PDFs merge multiple topics.

6. To allow one publication to link to another there needs to be a notion of identifying the publication.


Abstract Example:


We have two deliverables PubA and PubB which respectively have PubA.Source and PubB.Source representing the source content behind PubA and PubB respectively.

We wish deliverable PubB to refer to content in deliverable PubA.

We export the keys and thus topic addresses from PubA as contemplated in 13041 – these are called PubA.Source.ExportedKeys.  This allows the PubB source to confidently use these keys with keyrefs based on those keys.

When we publish PubA we create a translation table that for each entry in  PubA.Source.ExportedKeys creates an entry in PubA.KeyDeliverableAddresses.

When we publish PubB we use PubA.KeyDeliverableAddresses to resolve the keyrefs to PubA.Source.ExportedKeys to PubA deliverable addresses.


All possible fragment addresses in topics have to be generated because of not guarantee of stability in any address values in source content.


To me that is the essence of the two proposals – can we make this shorter and more clear?



From: dita@lists.oasis-open.org [mailto:dita@lists.oasis-open.org] On Behalf Of Eliot Kimber
Sent: June-20-13 3:08 AM
To: dita@lists.oasis-open.org
Subject: [dita] Groups - Proposal 13120 (HTML) uploaded


Submitter's message
HTML rendition
-- Eliot Kimber

Document Name: Proposal 13120 (HTML)

Defines vocabulary for use by multi-pass processors implementing
cross-deliverable addressing using intermediate key definition sets.
Download Latest Revision
Public Download Link

Submitter: Eliot Kimber
Group: OASIS Darwin Information Typing Architecture (DITA) TC
Folder: Drafts
Date submitted: 2013-06-20 03:07:40


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