OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [xliff] csprd02-111 (changes for matches module)

Let's see what other think and test how it works for their implementations.

-----Original Message-----
From: Schnabel, Bryan S [mailto:bryan.s.schnabel@tektronix.com] 
Sent: Thursday, October 10, 2013 6:41 AM
To: Yves Savourel; xliff@lists.oasis-open.org
Subject: RE: [xliff] csprd02-111 (changes for matches module)


This level of uniqueness is quite rational and will help in the use cases I've been working on the past few weeks.

If you are proposed these approaches (unique IDs for segments and inlines; dupes ok between source and target; no additional IDs
required), I would second.



-----Original Message-----
From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Yves Savourel
Sent: Thursday, October 10, 2013 3:47 AM
To: xliff@lists.oasis-open.org
Subject: [xliff] csprd02-111 (changes for matches module)

Hi all,

Looking more at David-O's proposal on how to avoid pointing to <mrk> when pointing to a segment content, and talking with David-F
and Chase yesterday:

I think it would be reasonable to have <segment>, inline annotations and inline codes use IDs that are unique within the <unit>
element (with the caveat of the <source>/<target> duplication obviously). The rational is that they all constitute anchors within
the same content. David-O's proposal affects only <segment> and <mrk>/<sm>, but extending ID uniqueness to the inline codes as well
may help avoiding unforeseen problems for future modules which may need to point to any of the inline constructs.

From an implementation viewpoint, there is already some common objects at the <unit> level, so sharing a unique ID mechanism at that
level is unlikely to be an issue.

I'm not especially for requiring IDs where they are currently not required. For example if a tool implements the Translation
Candidates module and need to point to a <segment> currently without ID, it can create the ID. The rational here would be to allow
simple tools to keep things simple.


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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]