OASIS XML Localisation Interchange File Format (XLIFF) TC

  • 1.  csprd02-111 (changes for matches module)

    Posted 10-10-2013 10:47
    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. Cheers, -yves


  • 2.  RE: [xliff] csprd02-111 (changes for matches module)

    Posted 10-10-2013 13:41
    Yves, 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. Thanks, Bryan


  • 3.  RE: [xliff] csprd02-111 (changes for matches module)

    Posted 10-10-2013 21:13
    Let's see what other think and test how it works for their implementations. -ys