OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [xliff] Fragment Identification

Yves, Dave

On Mon, Dec 16, 2013 at 8:31 PM, Yves Savourel <ysavourel@enlaso.com> wrote:
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)
For all published modules these prefixes are part of the spec, so no problem at all
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
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 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
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
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?
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
This is pointing to <glossEntry> or <translation> with gls:id="1" within <unit> with  id="2", within <file> with id="1"

*There is one very important point that Dave made, i.e.
as far as you can internally reference across units and files, each of the three solutions, disregarding their syntactic or scope differences may force you to read the whole xliff file to resolve all references..

Dr. David Filip
University of Limerick, Ireland
telephone: +353-6120-2781
cellphone: +353-86-0222-158
facsimile: +353-6120-2734

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]