Thanks, Yves,
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:
On Wed, Jan 15, 2014 at 8:41 PM, Yves Savourel <> wrote:
Hi David, all,
The case of the Translation Candidates module is very difficult to address. I’m not sure it can be addressed properly.
A module/extension must abide by the constraints of id usages as described in section “4.9.2 Constraints”. So a module like
Translation Candidates that uses parts of the XLIFF core is in trouble:
In this case we cannot say that a third-party namespace (here the core) used by the module, must abide by the same rules (having
unique id values for the full sub-tree corresponding to the module) as it would break the core requirements that two identical
inline codes (one in source and one in target) must have the same id (and vice-versa).
I agree that this is a show stopper for the general scope option
As for the question of making modules/extension containers in the fragment identification mechanism:
> I guess that the solution would be to take the mtc prefix out
> of the list of terminal prefixes and say that one more
> terminal prefix can follow mtc
Mmm... maybe that may be simpler than a general solution. But we need a mechanism that can work with all module/extensions. What if
another module make use of the core namespace in the future? We would have to modify this behavior and change the version of the
core.
The more general solution to make all extension/module be potential container rather than terminal sounds better, but it look very
hard to implement (nested extension/modules like mda in mtc here).
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..
> Another way would be to adjust the uniqueness scope within mtc
> and say that everything, no matter if core or mda used within mtc
> must share the uniqueness scope with the required match id.
Can't do that: that would make source/target inline codes having different ids when they are the same.
I agree you addressed that before you came here :-)
Besides the search for the fragment is done among the elements of the mtc not the mda or core elements.
BTW, an important note of Lynx and the Okapi library: remember that it implements only the core, so while the schema validation is
done for both core and modules, the processing requirements/constraints part is done only for the core.
I guess we need to think.
-ys
From: Dr. David Filip [mailto:]
Sent: Wednesday, January 15, 2014 4:06 AM
To: Yves Savourel
Subject: fragid in mtc
Yves, all, I asked in the meeting on January 7, before we approved the fragid solution if pointing to core and mda elements within
mtc will be possible.
There was no time to resolve this in detail, yet it seemed somehow possible.
Nevertheless, looking at it now, it does not seem possible, or at least not without some qualification of the current provisions.
The current fragid constraint only allows to appear prefixes from the list of terminal perfixes to appear more than once.
However, if you wanted to identify a core target inline element within mtc, you would need to use both the mtc prefix and the target
prefix.
The situtuation is the same if we wanted to reference an mda element within mtc.
I am not familiar with the ABNF notation or what you have used to define the format of our fragid, but looking at it I believe that
iteration of prefixes is not prevented by the ABNF syntaxt, it seems an aditional prose constarint to me.
I guess that the solution would be to take the mtc prefix out of the list of terminal prefixes and say that one more terminal prefix
can follow mtc
Another way would be to adjust the uniqueness scope within mtc and say that everything, no matter if core or mda used within mtc
must share the uniqueness scope with the required match id.
Any thoughts?
Cheers
dF
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:
---------------------------------------------------------------------
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
