[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. Givens: 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 Submitter's message
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]