RE: [xliff] Comments on Fragment Identification

[Yves Savourel <ysavourel@enlaso.com>]

Hi David, all,

Thanks for the comments, here are a few other:


> 1) having several scopes and many prefixes
> 2) having a few scopes and no need for prefixes in core

1 tries to reflects the reality of the data.
2 foists restrictions on the data in order to make things fit a specific notation


> you say that splitting the id note scope is a show 
> stopper, but it is what allows for only two internal 
> id scopes and makes the referencing mechanism manageable.

Not sure what you mean by "manageable". In both case you have to write specialized code to deal with the fragment identifier.
Besides, what looks "manageable" in XLIFF may not be so easy on the implementations using the IDs.

In my opinion your notation brings several issues that make it less attractive:

- no handling of source/target difference for inline Ids.

- two fragments identifiers can be identical but mean different things depending if they are in a full URI or not.

- grouping too much the ID scopes to end up with only three scopes, just to make the notation work in XLIFF. Remember than XLIFF is
just an exchange format. Here you are changing what the data could be in order to try to make it fit the XLIFF representation.

- and a few other things mentioned in my previous email.


> ... we can go for another separator,
> I would propose ~ rather than /
> I know that they should not have issues with / but 
> really we are not working with directories or folders

The character / is commonly used separate levels in many context, not just directories, for example: tree locations, XPath
expressions, etc. Also I used ~ for the source/target case.


> What I intended to say was that things like this #1 can 
> only reference within a given <unit> or <file>.

Yes, and I did understand correctly.
That means you cannot refer from inside a <unit> to outside, or vice-versa.
That's a major limitation in my opinion.


> And also we do not want to encourage referencing 
> across units or files, so that should be OK.

Why? You may want to have data living at the file level that need to be pointed to from within a <unit>. The Resource Data module
does exactly that. You may want to do this type of referencing from an <mrk> for example, or from a future module (like ITS).


> Finally, shouldn't we use IRIs rather than URIs?
> I hope there is not much impact anyway, except 
> that other than Latin script characters will be 
> allowed as values.. 

I think IRI should be find.

Cheers,
-yves