RE: [xliff] id scopes again

[Yves Savourel <ysavourel@enlaso.com>]

Hi David,

> I believe that we have now an issue with optional ids 
> on groups and notes or at least on groups.

We can certainly re-visit that: Our discussion on that was before the Fragment Identifiers issue came up.


> Does not seem a big issue, because if you need to reference 
> a note you simply assign an id to it and you can reference it, right?
> Not really, actually the referencing will still fail if the note 
> is on a group without an id.

No, it won't fail. The only place you use a URI to point to a note is in a comment annotation.
And according the constraint you added since csp02 such reference can only point to a note within the same unit.

Old text:

"ref - When used in a comment annotation, the value is referring to a <note> element."

New text:

"ref - When used in a comment annotation, the value is referring to a <note> element within the same enclosing <unit>."

In other words: you point to that note using simply: ref='n=idOfMyNewNote'.


> However, now you are forcing a simple enricher that was just supposed 
> to ad prose comments in a simplest possible way to check for existence 
> of ids on parent group elements and ...

The tool only needs to check the IDs of the notes existing in that <unit> to be sure to not have a duplicated value. Or it can use a
UUID and doesn't even need to check anything.

...Or are you saying now that a comment can point to a note outside the unit?

That would be what the US politicians would call a "flip-flop" and British journalists a "reverse ferret". And there is nothing
wrong with that: one can change his mind.

> Now the same complication is repeated for every 
> module that has elements allowed on group.
> Therefore I strongly recommend that id on group is made REQUIRED.

We saw that the note argument doesn't hold. But, overall from the viewpoint of implementing the fragment identifier mechanism, it is
indeed rather annoying to have to check for group id. In the light of with that argument, I think it would be OK to have required id
on groups.


> Further, I believe that also note ids should be required.
> If note ids remain optional, I would at least add a Warning on the note 
> element and in the fragid section that agents might need to add note 
> ids in case they want to reference them.

Terminal parts of the URI fragments (notes, segment, ignorable, etc.) are much less problematic than container parts (like group)
with regard to not having ids: you need ids only if you point to them.

You say "I believe". But what is the rational to have required id on <note>?

For instance, an <item> of the Change Tracking module can point to a note id, but can it point outside the unit where it resides?
I'm not quite understanding the definition: "The value of the ref attribute MUST be the value of the id attribute of a single
instance of an element that is a multiple instance within the enclosing element."
 

Cheers,
-yves