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: Unique topic ids in the cross publication or global CMS use case

Hi Folks


I have found numerous discussions that topic id is not required to be unique within a publication or collection of topics – none of these discussions in the current 1.2 specification (that I could find anyhow) – although omission means no requirement.

One such reference was: http://tech.groups.yahoo.com/group/dita-users/message/14260

Of course topic id does have to be unique within an XML document – that is not what I am talking about here – rather I am addressing intra publication uniqueness or even global uniqueness.

Some PDF processors, such as the PDF5 processor for Antenna House, however, require that topic ids do have to be unique within a publication.

At first it seems like this requirement is overstepping what Oasis has recommended (or not recommended through omission).  However, one reason for this unique id requirement of PDF5 is to support the cross publication linking use case.

It just so happens that we dealt with this use case recently in approving proposal 13041 (Facility for key-based, cross-deliverable referencing (Kimber)).

It seems if we do not recommend or say anything about unique topic ids, then we leave processors to “twist in the wind” – or make extra requirements like PDF5 did.  On the other hand, if we require unique topic ids, we might be pre-supposing certain implementations which in fact are not necessary.

It seems, however, if we are to add proposals such as 13041, then we might want to talk about how cross publication linking might happen – this proposal 13041 opens the door to some new possibilities. 


For example, if our references were key rooted, we can used key export tables and the processors could do something like the following:


I use a PDF example here but it may have bearing on other cross publication links such as cross chunked HTML.

In PDF, for example, to allow processor defined unique ids to topics for the purposes of merge (Like PDF2 merge) then to link from PDFB to PDFA would require PDFA to export its external links to PDFB because the ids of the topics in the PDF are not known at author time.


PDFA (export as XML)


keyname    newMergetopicId                      Original fragmentId

MyKey1      a223345                                       be3333333


Then PDFB consumes this and has a reference to MyKey1/be3333333


Then when a processor builds PDFB and when it references PDFA with MyKey1/be3333333 it would resolve to PDFA.a223345/ be3333333


In this case, a223345 could be entirely generated by the PDF processor when PDFA is built, however, be3333333 would remain stable but not unique as a fragment Id.


My question here is, should we say something in the spec or when we document proposal 13041 regarding this.  Should we have text that says “we DO NOT recommend processors rely on unique topic ids within a publication” or “we DO recommend – same”.




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