RE: [xliff] Fragment Identification

[Yves Savourel <ysavourel@enlaso.com>]

Hi David, Dave, all,

>> Mmm... the registration aspect is a bit problematic:
>> Aside from having to do the registration,
>
> The registration simply is that each module (eventually extension)
> that has ids must declare their 2-5 nmtoken that combined with some
> core syntactic device (such as / or ~ propsed by me or = proposed
> by you)

Declare where?

I'm Tool ABC performing a simple task of checking that all <mrk> elements with a reference actually point to something that exists,
or I'm Tool XYZ doing some clean-up and removing all annotations with references pointing to nothing.

I have this ref to look at: #f=f1/foo=23"

- I can guess foo refers to a module or an extension,
- but how do I know the namespace of the elements where I need to search for id="23"?



> For all published modules these prefixes are part of the spec, so 
> no problem at all

- Tool XYZ is core only and doesn't know anything about modules (aside that they have a namespace URI that starts with a specific
pattern).
- Tool ABC is based on specification 2.0 and doesn't know anything about the new 2.2 foo module.

Both have a problem.



>> there is the issue of how does a tool know which prefix corresponds
>> to which extension?
>
> Only people who support the extension will know that.
> Others will know that it is an extension prefix, because it 
> complies with the extension prefix syntax, e.g
> /foo or foo=
> And they will happily ignore it

As shown above Tool ABC and Tool XYZ cannot happily ignore it and do not know about the corresponding module/extension.



>> It has to somehow keep up with the registry. It's doable but it 
>> starts to get very complicated.
>
> No need to keep registry of extensions, only module extensions 
> are guaranteed to resolve 

I'm probably not understanding what you mean by "only module extensions are guaranteed to resolved".

If there is no registry for extensions, how do tool know which prefix are used by other tools?
How do they know which prefixes are used by newer modules that didn't exist in the spec that existed when they were build? 



>> I was thinking about using the namespace prefix used for 
>> the module/extension in that document.
>
> In my proposal I use the default module prefix as the nmtoken part 
> of the module prefix

That was a good first step.
But the prefix used in the specification is not necessarily the prefix used in the real XLIFF documents. Actually nothing even
prevent the same namespace to use different prefixes within the same document.


> The scope is what the module extension id attribute defines
> the gls id scope is each <glossary> element 
> so locally you can reference #/gls~1
> This points to the <glosEntry> or <translation> with 
> gls:id="1" in the same <unit>
> If you wanted to points to a <glossEntry> or <translation> 
> in another unit, which I strongly believe should be forbidden 
> (I only allowed the option in my proposal because everyone 
> seemed to be eager to have it)* you would need to go
> #1~2~/gls~1
> This is pointing to <glossEntry> or <translation> with 
> gls:id="1" within <unit> with  id="2", within <file> 
> with id="1"

So #/f=1/u=2/gls=1, I guess that would work as long as we can come up with a solution for the prefix for the modules/extensions.


> If you wanted to points to a <glossEntry> or <translation> 
> in another unit, which I strongly believe should be forbidden

I assume you are talking about the general case of an annotation pointing outside the unit where it exists here.

I think there will be cases when people will come up with modules/extensions that require such pointing.
The TBX case of ITS Terminology annotations created by Tilde (here: http://taws.tilde.com/xliff) is an example of that.

Cheers,
-yves