On Mon, Dec 16, 2013 at 11:22 PM, Yves Savourel <ysavourel@enlaso.com> wrote:
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?
In their spec, each 2.0 module has now a section (as part of the solution that have proposed) that contains their prefix
I assume extensions will have their documentation shared at least among those who support them, it would be a good idea for them to have some section upfront similar to our module definitions, where they declare their namespace and prefix..
I'm Tool ABC performing a simple task of checking that all <mrk> elements with a reference actually point to something that exists,
That task is not simple and you can actually only perform it for modules or extensions that you support
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"?
You know that it is a module or extension on f1. You cannot be sure what is the proper namespace without supporting the foo module or extension
YS> I don’t think that is an option. Tools should be able to perform generic tasks on extensions/modules. If resolving a reference to a module requires the tool to know about the module there is no really any point in defining a general way to resolve fragment identifiers.
> 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.
If you know it is an extension, you can eventually kill it if it causes you trouble, that is the meaning of SHOULD preserve, i.e. preserve unless it's causing trouble.
YS> You’re missing the point: in the examples the tasks are to verify or remove annotations with references pointing to nowhere, no to kill extensions.
BTW both mtc and gls are now designed to reference using their own ref pointing to core only, so they are not likely to cause trouble
YS> BTW: why Matches and Glossary ref attributes are using URI values? They could be just ID values if it always point within <unit>. Just like the ref of res:resourceItemRef which has also a prescribed “landing area”.
But that doesn’t change the problem for any modules/extensions or any non-XLIFF document that wants to point to a match/glossary entry.
>> 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.
If the tool wants to perform the cleaning task on a 2.2 Document it should be aware of all 2.2 module prefixes. Otherwise it can only clean 2.0 files.
It can eventually kill extensions that are not registered by 2.2
YS> Again I don’t think that’s an option: the task is exactly the same regardless the version: the tool should not have to be updated each time a new module is added just because there is a new fragment identifier prefix to take into account. That’s the whole point of having modules/extensions.
Keep also in mind that non-XLIFF tools may want to resolve XLIFF URIs.
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.
I think that we have the solution, the only point of contention is if we register them somewhere apart from the module definition itself.
YS> What is that solution then?
Because if it’s what is in the latest spec I disagree.
For the extensions/modules prefix I think there are several options:
- 1. Using the namespace’ prefix. It’s self contained, it’s a known mechanism any XML parser can use, it’s independent of version, etc. The main drawback is that it’s not a persistent address: the prefix may change and then the external document pointing to the element would be broken. So I’m not liking this very much for that reason.
- 2. Another option is to have fixed prefixes. The drawback is that tools need to be able to access some kind of official online registry that maps the prefix to a namespace, and such registry needs to be maintained.
- 3. Another option may be to use the module/extension namespace URI itself: that would have all advantages, but the drawback would be very long references. I’m also not sure a URI string could be used as part of a fragment identifier.
- 4. And another option would be to have a core element that defines the mapping between prefixes and namespaces inside each file. That would avoid the whole registration issue. But essentially that would have the same issue as the namespace: the mapping could be modified and the external pointers would be broken.
Options #2 and #3 would seem the least-worst.
Cheers,
-yves