[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xliff] IDs - uniquness per type of element (C)
Thanks Yves,I think that we did not resolve how spans will be reference back from translation candidates module, but this is actually a separate issue..We kind of agreed that id on both segment and ignorable are OK to stay optional rather than required.We also agreed that the algorithm to determine translatability state will be simpler if translate is killed on segment.As I see, it it is natural that all inlines (codes and annotations) have required ids or refs having a single uniqueness constraint within unit.Now both markers and segments are slightly different ways how to delimit spans in the whole unit.Since both have the same scope I think there is no harm in their being unique also against each other, disregarding if this property is currently used by a core or module mechanism or not. I simply believe that it is a cleaner design.Based on all the discussions we had in this list and in the teleconefernce conference, it seems clear to me that id uniqueness has only two main scopes in XLIFF 2.0, this is file and unit (ignoring data for now). I think that is natural and better for general referencability if core ids are truly unique within these two scopes.
optional ids on groups must not compete with required ids on unitsandoptional ids on segments and ignorables must not compete with required ids on inlines.I think it is not an unreasonable burden on Writers who need to add those optional ids, eventually on Extractors who would use them upfront..RgdsdFDr. David Filip=======================LRC | CNGL | LT-Web | CSISUniversity of Limerick, Ireland
telephone: +353-6120-2781cellphone: +353-86-0222-158facsimile: +353-6120-2734mailto: david.filip@ul.ieOn Fri, Nov 8, 2013 at 1:57 PM, Yves Savourel <ysavourel@enlaso.com> wrote:
Hi David,
I think there was no dissent on having inline codes and annotations be unique within the unit.
But I think the case of segment is still not resolved: Fredrik was still discussing this at this week’s call. And we didn’t have a conclusion on this as the discussion derived to translate being useful or not on segment and about ignorable.
At this point I don’t think we’ve resolved yet how to point to the content of a segment: by using the segment ID or by using a mrk enclosing the whole segment content?
Cheers,
-ys
From: Dr. David Filip [mailto:David.Filip@ul.ie]
Sent: Friday, November 8, 2013 6:04 AM
To: Yves Savourel
Cc: xliff@lists.oasis-open.org
Subject: Re: [xliff] IDs - uniquness per type of element (C)
Since there was no dissent on this one since Oct 22, I assume that this can be implemented
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
mailto: david.filip@ul.ie
On Tue, Oct 22, 2013 at 6:42 PM, Yves Savourel <ysavourel@enlaso.com> wrote:
Hi David, all,
> *C)*
> Although this is not explicitly stated anywhere in the spec it
> is clear from examples etc. that ids are expected to be unique only
> for certain elements within the given scope.
> For example, there is a tacit assumption that there can be a marker
> AND a segment with id="1" within the same <unit>
>
> Possible solutions:
> 1. Kill this silent assumption and make clear that ids MUST be really
> unique within the given scope disregarding on what element they
> are specified.
> This would not mean a big implementation burden. In the above example
> the segment could be id="s1" and the marker be id="m1". Any ref within the
> scope would be able to simply point like this ref="#s1" or ref="#m1" w/o
> the need to specify ref type or introducing a custom type for pointing
> within a specific element subscope.
> Pros: Makes addresability easier. refs within scope can be of the type
> URI or IRI w/o further issues
> Cons: This goes against a long standing assumption/tribal knowledge that
> is the harder to kill because it was never explicitly stated
> ...
> *Proposed solution: 1.*
+1 to option #1.
<segment>, <ignorable>, <mrk>/<sm>, <ph>, <pc>/<sm>/<em> must have unique ID within their <unit>.
Note that the matches modules may add inline codes and annotation within the same <unit>. But this is out of the scope of the core
constraints. (And I don't think we need to have a note about that).
-yves
---------------------------------------------------------------------
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]