RE: [xliff] Fragment Identification

[Yves Savourel <ysavourel@enlaso.com>]

Hi Dave, all,

> For modules they should define their own two to five character 
> prefix (as David suggested) to be used for references. The prefixes 
> should be registered with the TC to avoid conflicts. 

Mmm... the registration aspect is a bit problematic:
Aside from having to do the registration, there is the issue of how does a tool know which prefix corresponds to which extension? It
has to somehow keep up with the registry. It's doable but it starts to get very complicated.

I was thinking about using the namespace prefix used for the module/extension in that document. The problem is that such prefix
could change if the document is re-written.
Self-declared prefixes would be about the same as using the namespace prefix. With likely less chances to have the prefix be
modified.
But, I do not like that non-persistence aspect in both cases.

I also assume the scope of the ids for module/extensions would be the <file>, right?



> That is true, having groups and units share their scope leads 
> to shorter references (as ids on groups are irrelevant since the 
> units are guarenteed to be unique within the given file). 
> On the other hand, you must ensure each unit in a given file 
> has a unique id for all groups in that file. 
> What are your objections to this?

Groups and units are different classes of objects, there is no reason in a CAT/TMS tool that they share a unique ID space. Keeping
them separate in XLIFF allows the tools to have either cases internally.

I don't think having shorter URI Fragment identifiers in XLIFF (just an exchange format) is a good enough reason to foist such
constraints upon the tools. This could lead to tools starting to use extensions to carry their real ids.

The fragment identifiers issue can be resolved without that change, so to me the question is more: what is the justification for
such a change?


Cheers,
-ys