[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xliff] Fragment Identification
Hi David, Dave, all,
Declare where?
>> 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)
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"?
- Tool XYZ is core only and doesn't know anything about modules (aside that they have a namespace URI that starts with a specific
> For all published modules these prefixes are part of the spec, so
> no problem at all
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.
As shown above Tool ABC and Tool XYZ cannot happily ignore it and do not know about the corresponding module/extension.
>> 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
I'm probably not understanding what you mean by "only module extensions are guaranteed to resolved".
>> 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
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?
That was a good first step.
>> 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
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.
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.
> 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"
I assume you are talking about the general case of an annotation pointing outside the unit where it exists here.
> If you wanted to points to a <glossEntry> or <translation>
> in another unit, which I strongly believe should be forbidden
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
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]