RE: idValue requirement updated

Hi Dave, all,

> This solution seems to rely on the XML schema having 
> specific cardinalities, so it will only work with certain 
> classes of element structure, is that right?
> For example, this approach would not work in your 
> example if the cardinality of the text and desc 
> element within the msg element was not exactly 1.

Correct.


> Did you consider just inserting an id for elements 
> that do not already have an id in the source. 

Not really. For different reasons:

a) The original format should be the one providing the IDs in the first place. Having something like "id1-desc" is just a side effect of using XPath which happens to be powerful enough to let you do this.
I'm not sure ITS should help work around the limitation of the original format, ideally the original format should be adjusted to follow internationalization best practices.

b) Most of the time we cannot change the original document. In this example, if there is no id attribute for <desc>, well we can't just add one and send it back like that to the customer. Like you noted:

> ...but we could control that by using an id value convention 
> that allows you to distinguish 'native' id from any id added
> by ITS processes, e.g. id="its-12345" from id="12345".
> This way the added its ids can be reliably stripped once 
> they are no longer needed, leaving the original source 
> ids (which may have other, nonlocalsiation requirements) intact?

You don't need to add an id to the original document if it is your id. You can just generate it on the fly. But how would it be replicated to be the same on the next version of the same document?

The only way to come close to that would be to use hashes of each content. But that's far from ensuring uniqueness or replicability.

In this example, you can improve that by using something like parent id + hash on the content of <desc>. It'll help on replicability but there is no guarantee that it'll be unique.

Cheers,
-yves

Received on Tuesday, 1 May 2012 11:29:25 UTC