Re: idValue requirement updated

On Tue, 2012-05-01 at 10:43 +0100, David Lewis wrote:
> Hi Yves,
> 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.

I don't think this is a problem with the proposal.

 selector="//desc" idValue="concat(../@name, '_d')"

 <msg name="id1">
  <text>Value of text</text>
  <desc>Value of desc</desc>
 </msg>

This is unique iff a msg can have at most one desc. If a msg can
have multiple desc elements, it obviously is not. But then you
should use something like

 idValue="concat(../@name, '_d', count(preceding-sibling::desc))"

To write correct rules, you have to know what's allowed in the
target XML vocabulary. If you write rules with false assumptions,
it's not really the fault of ITS.

> Did you consider just inserting an id for elements that do not already 
> have an id in the source. Obviously this impacts on the structure of the 
> document, 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?

Would these be IDs inserted into the infoset? You can't reliably
create dynamic ID values that are consistent across multiple runs.
The XSLT generate-id() function is only required to generate values
that are consistent in a single run of a transformation.

Even if you created IDs that are consistent across multiple runs on
the same input (something like XPointer's element scheme), it would
be prone to break if things are shuffled in the source document.
Using known unique and invariant data in the document seems much
more reliable to me.

--
Shaun

Received on Tuesday, 1 May 2012 13:40:54 UTC