Re: [dita] Proposal 13042: @objid Attribute

[Eliot Kimber <ekimber@rsicms.com>]

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/