Hi Phil,
Ø Is this not the constraint that we spent some meetings discussing and coming to the conclusion that at best is was ambiguous and that it would be removed?
Possibly. It seems the inline code IDs in <match> would also break this constraint.
But it doesn’t look very ambiguous in the 2.0 specification.
Cheers,
-ys
From: Phil Ritchie [mailto:phil.ritchie@vistatec.com]
Sent: Monday, December 12, 2016 2:40 PM
To: Yves Savourel <ysavourel@enlaso.com>; 'XLIFF Main List' <xliff@lists.oasis-open.org>
Subject: RE: [xliff] Change tracking questions
Yves
-----8<-----
> For example the id value of a segment may exists twice: in the true content
> and in one (or more CTR entries). If they do have the same values, they
> break the constraint of http://docs.oasis-open.org/xliff/xliff-core/v2.0/xliff-
> core-v2.0.html#id where the specification says that when id is used with
> segment "...the value MUST be unique among all of the above (segment,
> etc.) within the enclosing <unit> element."
-----8<-----
Is this not the constraint that we spent some meetings discussing and coming to the conclusion that at best is was ambiguous and that it would be removed?
I feel guilty that as one of the main proponents of ctr I haven't more time to dedicate to it right now.
Phil
>
Phil Ritchie
Chief Technology Officer | Vistatec
Vistatec House, 700 South Circular Road,
Kilmainham, Dublin 8, Ireland.
Tel: +353 1 416 8024
Email: mailto:phil.ritchie@vistatec.com
http://www.vistatec.com | ISO 9001 | EN 15038
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify mailto:phil.ritchie@vistatec.com. This message contains confidential information and is intended only for the individuals named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify mailto:phil.ritchie@vistatec.com immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.
-----Original Message-----
> From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf
> Of Yves Savourel
> Sent: 12 December 2016 20:59
> To: 'XLIFF Main List' <xliff@lists.oasis-open.org>
> Subject: RE: [xliff] Change tracking questions
>
> Hi all,
>
> I've spend most of the week-end and a big part of today trying to implement
> CTR 2.1 and I'm not making much progress. Simple examples may work fine,
> but with real life content things are not working well.
>
> -- Out of context issues
>
> As we store content in unitItem and contentItem, there is the issue of
> context that crops up: Some information like xml:space or translate go across
> segment, or even across units, and may not have a physical representation in
> the XLIFF snippet we store.
>
> For example taking a segment content out of the context of its surrounding
> other segments may hide the fact that it is not translatable because there are
> some <mrk id='1' translate='no'> in the previous segment.
> That information cannot be stored in <contentItem>. It may be OK, but that
> may also have side effect when restoring the data in a different context.
>
> Another illustration of context issue: <mrk type='comment' ref="#n1"> is a
> comment referring to a note. If we store this in, for example, an
> <itemContent> because the translation has changed, there is no guaranty
> that the note n1 will stay there, or even point that n1 corresponds to the
> same note after some other changes. So we can end up with invalid
> references.
>
> Overall, it seems the content of a <revision> is bound to break the normal
> content constraint at some points because a) It is stored in a different
> context and b) It is not stored with all its 'dependencies'.
>
> -- Validation troubles:
>
> We say we do not want orphan <mrk>, but there are other validation issues
> with the stored content.
>
> For example the id value of a segment may exists twice: in the true content
> and in one (or more CTR entries). If they do have the same values, they
> break the constraint of http://docs.oasis-open.org/xliff/xliff-core/v2.0/xliff-
> core-v2.0.html#id where the specification says that when id is used with
> segment "...the value MUST be unique among all of the above (segment,
> etc.) within the enclosing <unit> element."
>
> I'm running into a lot of problems when trying to read back contentItem and
> unitItem.
>
> Cheers,
> -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
VistaTEC Ltd. Registered in Ireland 268483.
Registered Office, VistaTEC House, 700, South Circular Road, Kilmainham. Dublin 8. Ireland.
The information contained in this message, including any accompanying documents, is confidential and is intended only for the addressee(s). The unauthorized use, disclosure, copying, or alteration of this message is strictly forbidden. If you have received this message in error please notify the sender immediately.