XLIFF Inline Markup SC

 View Only
  • 1.  RE: [xliff-inline] 1.3. Must be able to represent paired codes that have been separated

    Posted 08-08-2011 13:26
    Hi Bryan, > I would strongly advocate for idref over (second/paired) > id, rid, or idr. As a long time XML hacker, I think idref > has a rich and understood tradition of being paired with > id. And frankly, the brevity of the other choices (by a > character or two) does not seem very compelling to me > (my bias: clarity trumps brevity). I have no problem with idref. But there are currently two attributes in the code elements that hold reference to another id. The other is "nid", which points to an element in the outside structure that stores the original data. Technically it is also an "idref", no? What would be the rational to prefer one over the other to be named idref? -ys


  • 2.  RE: [xliff-inline] 1.3. Must be able to represent paired codes thathave been separated

    Posted 08-09-2011 00:10
    Hi Yves,

    I have no rationale to prefer one over the other to be named idref. It was an oversight - my fault for not taking the larger set of issues into account.

    I see "nid" referred to in 1.12.3.1. Is there something to do with the "n" in "nid" that makes it intuitive for its use? If not I would prefer it to be an idref as well.

    - Bryan




  • 3.  RE: [xliff-inline] 1.3. Must be able to represent paired codes that have been separated

    Posted 08-09-2011 03:34
    Hi Bryan, > ...I see "nid" referred to in 1.12.3.1. Is there something > to do with the "n" in "nid" that makes it intuitive for > its use? 'n' was early on for 'native'. I agree: it's not a good name. Something like 'dataRef' would be clearer probably. > If not I would prefer it to be an idref as well. We cannot use idref twice in the same element :) Hence the questions: Which one should be called idref? And why? (so we can justify the choice with a rationale) -ys