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


Jim,

I think you've correctly captured the essence.

As to your question "can we make it simpler or shorter?" I don't know. It
seems about as short and simple as it can be and still be accurate, but I
will leave that challenge to others. I can generally guarantee accuracy, I
cannot guarantee brevity :-)

The only thing I would quibble with is your last statement:

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

The reason you need to generate a key for each addressible element is not
the stability of the addresses but the fact that you can't predict what
other publications might want to link to them, in the general case.

All addresses are inherently unstable--as soon as you create a new version
of any component of a publication all bets are off because it's a new thing,
again in the general case.

In practice addresses tend to be more more stable than not just because it's
good practice not to let things be more chaotic than they need to be, but it
may still be the case, for example, that the details of generated IDs are
sensitive to initial conditions.

Cheers,

E.


On 6/21/13 11:40 PM, "Jim Tivy" <jimt@bluestream.com> wrote:

> 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
> 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)
> <https://www.oasis-open.org/apps/org/workgroup/dita/document.php?document_id=4
> 9631> 
> 
> Description
> Defines vocabulary for use by multi-pass processors implementing
> cross-deliverable addressing using intermediate key definition sets.
> Download Latest Revision
> <https://www.oasis-open.org/apps/org/workgroup/dita/download.php/49631/latest/
> proposal-13120-vocab-for-publishing.html>
> Public Download Link
> <https://www.oasis-open.org/committees/document.php?document_id=49631&wg_abbre
> v=dita> 
> 
> Submitter: Eliot Kimber
> Group: OASIS Darwin Information Typing Architecture (DITA) TC
> Folder: Drafts
> Date submitted: 2013-06-20 03:07:40
>  

-- 
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/



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