[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dita] Proposal 13042: @objid Attribute
Ah--I see the problem. Yes, in that case, having the original object ID would be an easy way to solve the re-import problem and establish effective identity across the copies of any given topic or map. You could, of course, do it through file naming conventions or whatever, but having the data in the topics is going to be more robust and possibly easier to implement depending on how the system works. Cheers, E. On 6/17/13 6:38 PM, "Bob" <bob.thomas@tagsmiths.com> wrote: > 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 <ekimber@rsicms.com> 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" <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> <tel:512.554.9368 >>>> <tel:512.554.9368> > >>>>>> www.rsicms.com <http://www.rsicms.com> <http://www.rsicms.com> >>>>>> www.rsuitecms.com <http://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 <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/ >> > > -- 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]