[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: fragid in mtc
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). 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). > 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. 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:David.Filip@ul.ie] 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: david.filip@ul.ie
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]