RE: [xliff] RE: fragid in mtc

[Yves Savourel <ysavourel@enlaso.com>]

Hi David, all,

> The solution should be implemented in the spec like this
>
> Take out modules and extensions from the list of terminal selctors
>
> Add a constraint saying that modules and extensions selectors are 
> terminal unless they reuse mda or core
> No other namespaces would be allowed to be reused, apart form the 
> registered extension/module namespace itself.
>
> As an implementer, you need to know for every/module extension 
> their container status
>
> From the registration point of view, it adds two columns
> mda allowed | core allowed
> yes/no      | yes/no
>
> eventually three
> container | mda allowed | core allowed
> yes/no    | yes/no      | yes/no
>

Why just mda and core? The solution would need to be more generic. Potentially any moduile/extension can have various third-party
namespaces. Like you mentioned: The Glossary or Translation Candidates modules allow extended elements.

The bottom line is: if extensions/modules can be containers for other namespaces, we can have an infinite set of options. We can
certainly define the BNF for that and the few constraints to go with it. What I'm worried about is the implementation: it would be a
difficult one. Trying to validate the expression will be even more difficult.

One of the main obstacles is the case of core elements being used in an extension/module: We cannot have different ID rules for the
"real" core and the core elements used like that, so it forces the implementers to treat core-in-exetnsion-ids differently that
extension-ids, and that in a recursive way: it's a nightmare.

I guess, we could make the special provision that core Ids used in a module/extension are accessible like module/extension (and
define a prefix for it) and the author would have to use unique ids. The only hiccup is the source/target inlines. Maybe we can
state that only the source is accessible when using the frag id mechanism on a core element? 

#mtc=m1/xlf=1 would access the inline code id='1' in the match id='m1' of the current unit.

#mtc=m1/t=1 would not be valid.

In other words: extensions/modules would be containers only of other extensions/modules.

Just thinking aloud.
But even that would be challenging to implement.

> where there must be a yes in the second or third column 
> if there is yes in the first.
>
> If you are checking wellformeddness of the fragids, you need to know 
> if the module/extension has container status, otherwise you would be 
> allowed to form fragids that will never identify, and necessarily so..
> or do you say that it would be OK to have e.g.
> ctr=1/t=1
> If modules/extensions were allowed to be fragid containers in general, 
> the above would be well formed, yet would necessarily fail to reference, 
> because ctr is not a container module.
>
> On the other hand if we allowed modules/extensions to be containers in 
> general, it should be possible in general to reference extensions of modules.
> Eg. gls has extensibility by elements
> Now there would be an additional complexity

> You would need to lift the constraint that modules/extensions can only 
> register one prefix, as they would need the additional prefixes for their 
> own extensions.

I'm not following that: they just have to register a prefix for each namespaces used in their extension.


-ys