Re: [xliff] RE: fragid in mtc

["Dr. David Filip" <David.Filip@ul.ie>]

On Wed, Jan 15, 2014 at 11:30 PM, Yves Savourel <ysavourel@enlaso.com> wrote:

> I think that the general solution would be to say that modules
> and extensions are allowed to reuse core and mda and IF and only
> IF they do so, they are no longer terminal but can act
> potentially as container, same as f´=, g=, and u= 
>
> I do not see why it should be so tough to implement, as you are
> using f=, g=, and u= the same way..

Actually the change only for some modules means you have to know which one should behave one way and which one behave the other way,
and have conditional codes, etc.
So doing it for all modules may be easier (well, less bad).

Yves, I do propose a general solution, sorry if it odes not seem so.

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

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.

Dr. David Filip

=======================

LRC | CNGL | LT-Web | CSIS

University of Limerick, Ireland

telephone: +353-6120-2781

cellphone: +353-86-0222-158

facsimile: +353-6120-2734

http://www.cngl.ie/profile/?i=452

mailto: david.filip@ul.ie