[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dita] Proposal 13042: @objid Attribute
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" <bob.thomas@tagsmiths.com> 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 <ekimber@rsicms.com> 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/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]