I should have been more specific. First, here is more information about the source CMS. Every time the source CMS exports a DITA map, the map's entire resource, dependency-tree gets exported, creating a collection that contains all resources needed to publish it. Moreover, each of the links within the dependency tree get translated so that they will resolve within the exported collection. The linking graph in the exported collection is valid and it is isomorphic with linking graph for the corresponding DITA map in the source CMS. This functionality passes the import-then-export test.
Now, suppose you had two bookmaps that re-use only a single front-matter topic (LegalStuff.dita). Exporting either bookmap results in a valid DITA collection (link-integrity preserved) that can be published. Exporting both bookmaps results in two separate collections, each of which contain an autonomous copy of LegalStuff.dita. The challenge for migration is how do you import these two autonomous collections into the target CMS such that both point to same instance of LegalStuff.dita? Merging the two collections does not work (there could be other same-named topic pairs that contain different content). Even if you applied ad hoc renaming during the merge, this solution would become unwieldy should several hundred publications need to be migrated. If the LegalStuff.dita object ID is not embeded in these autonomous copies of LegalStuff.dita or in the links to LegalStuff.dita there is no way to know these two publications were re-using the same topic in the source CMS.
Regards,
Bob
On Mon, Jun 17, 2013 at 9:14 AM, Eliot Kimber <> wrote:
That's an interesting use case, one I hadn't really considered. But I'm not
sure it's really a valid use case, in that what you did shouldn't be
necessary in the general case.
I think the fault is really in the original system (which may be why you
were migrating), in that it should have been able to export the DITA such
that all the references were correct in the content as exported, e.g. by
rewriting the pointers from the internal form of address to normal URLs and
DITA fragment IDs.
That is, it's a general requirement of hyperdocument management systems to
be able to both import and export content without loss of information,
inclusing any links among the components of the hyperdocument. This means
that if the content was correct before import (in terms of whatever general
processing rules the content reflects, e.g., a standard like DITD), it
should be correct following import (that is, as stored and accessed by the
management system), and should again be correct as exported in terms of the
general processing rules.
Or said another way: if what was exported only reflected non-standard
addresses only resolvable by the original CMS, then it failed the "works on
export test". One would hope that most CMS systems in common use do not fail
that test. Those that do not should never therefore cause this use case to
occur.
In the case where the import-then-export test succeeds, the original object
ID is (or should be) unimportant, either because it's not reflected in the
exported data at all, or simply becomes the topic IDs or part of the
filenames or whatever as part of the export process, but again, because the
links work, is not interesting as an object ID.
Of course, you may have other reasons to want to remember what the original
object IDs were and maintain a mapping from the old ones to any new ones,
but that's a different use case and one that I was never intending to
address with the object ID attribute.
Cheers,
E.
On 6/17/13 4:51 PM, "Bob" <> wrote:
> I agree that the attribute would not be useful to vendors of current CMS
> systems. However, there is another use-case. Earlier this year I completed a
> CMS migration project, from one vendor to another, where it would have been
> useful to have objid available on topic, map, image, and object. As it was, I
> ended up utilizing the xtrf attribute. Retaining source object IDs upon export
> was essential for preserving re-use during preconditioning--a "dictionary"
> substitution on references--for import to the target system. Having objid
> would help mitigate vendor lock-in by offering a point of inquiry for
> prospects during the CMS sales process.
>
> While the CMS migration use-case may not be obscure, it certainly isn't
> commonplace. Therefore, it still makes sense to remove this proposal from 1.3.
> I simply wished to note the additional use-case for future consideration.
>
> Regards,
>
>
> On Mon, Jun 17, 2013 at 4:56 AM, Eliot Kimber <> wrote:
>> In reviewing this proposal and starting to write it up, I'm coming to the
>> opinion that the potential benefit does not justify the cost in 1.3. While
>> the value is clear, it seems unlikely that it will actually be used in the
>> short or medium term, since any existing CMS systems will have already
>> implemented some solution to the general requirement of capturing object IDs
>> in DITA XML and it's unlikely they'll change just because we provide a new
>> standard.
>>
>> So I am proposing to withdraw this proposal.
>>
>> Cheers,
>>
>> Eliot
>>
>> --
>> Eliot Kimber
>> Senior Solutions Architect, RSI Content Solutions
>> "Bringing Strategy, Content, and Technology Together"
>> Main: 512.554.9368 <tel:512.554.9368>
>> www.rsicms.com <http://www.rsicms.com>
>> www.rsuitecms.com <http://www.rsuitecms.com>
>> Book: DITA For Practitioners, from XML Press,
>> http://xmlpress.net/publications/dita/practitioners-1/
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this mail list, you must leave the OASIS TC that
>> generates this mail. Follow this link to all your TCs in OASIS at:
>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>>
>
>
--
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/
--
Bob Thomas
+1 720 201 8260
Skype: bob.thomas.colorado
Instant messaging: Gmail chat () or Skype
Time zone: Mountain (GMT-7)
