Reference to opening code

[Yves Savourel <ysavourel@translate.com>]

Hi,

The more I look at the id and rid attributes, the more I think we could just have id.

We have currently something like this:

<sc id='1'/> some text <ec id='2' rid='1'/>

Where rid is used in the closing code to point to its corresponding opening code.

That rational seems to be that both opening and closing codes need to have a different id.

I think it may be true for the underlying implementations, but having this reflected in the XLIFF syntax is a) not necessary and b) has several drawbacks.

The implementations can generate distinct internal ids for both the opening and the closing codes by using some flag to the id. For example: "o1" and "c1" instead of "1" and "2".

One of the advantage of this is visible in the paired notation:

<pc id="1"> some text </pc>

In this case, the XLIFF content does not expose a separate id for the closing code. This proves it is not needed. In addition, in this notation, having internal ids being "1" and "2" instead of auto-generated ids like "o1" and "c1" is detrimental: the only way to access the closing code object is to have either a lookup mechanism or an extra link to the closing code in each opening one. With auto-generated internal id the counterpart codes can be find just based on the id.

If we look at other aspects:

-- Distinct XLIFF ids are not needed for pointing to the optional external storage either since we would have a specific attribute with its own values for that.

-- Same thing in the case of added codes using a reference to an original code: e.g. "<sc id='3' rel='1'/>". The rel can point to the same id for both the opening and closing codes as it's easy to distinguish them.

Not having a rid would make also the notation cleaner and shorter.

Any thoughts?
-yves