[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xliff] IDs - Optional attributes (E)
Hi David, Ø <file> MUST have specified either original or id, i.e. one of them is REQUIRED So you’ve changed your mind about this? Below you said: “I agree with dropping id from file and with the changed original definition.” -ys From: Dr. David Filip [mailto:David.Filip@ul.ie] Hi all, no one responded here, so I am going to make a call for dissent: <segment> id remains optional <file> MUST have specified either original or id, i.e. one of them is REQUIRED Please let me know by Monday if this does not seem OK dF 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 Fri, Nov 8, 2013 at 12:23 PM, Dr. David Filip <David.Filip@ul.ie> wrote: Hi everyone, Yves, this discussion slept for a while I will try and summarize, what was agreed, I am leaving aside the <ec> issue that is being handled elsewhere.. Let us revisit what is the agreed solution and I will point out a couple of loose ends that I currently see
I agree with dropping id from file and with the changed original definition.. However, shouldn't original become required?, eventually we could have one of original or id required?
This seemed to be the previous agreement, however: Due to the discussion on inline markers behavior, it seems to me that segment ids are OK to remain optional..
I agree This will be 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 Wed, Oct 23, 2013 at 2:15 PM, Dr. David Filip <David.Filip@ul.ie> wrote: Thanks, Yves, inline.. Apart from the issues discussed below, I noticed a potentially suspicious discrepancy.. While there is an optional id attribute on <ec> there is no id attribute on <em>, is there a reason for handling them differently? I guess it is because original codes can be orphaned in the sense that there is no corresponding start code anywhere in the scope, right? Whereas this is considered impossible for annotations? Just double checking that this was the intention of the Inline SC.. Cheers dF 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 Wed, Oct 23, 2013 at 12:44 PM, Yves Savourel <ysavourel@enlaso.com> wrote: Hi David, all,
If you mean the <mrk> an <sm> elements by markers, they already have required IDs. I see the thing is that each of the annotation types lists the id as required separately, so I would drop these requirements in the annotations section as it seems confusing, probably as a result of marker ids being optional in a previous versions
Let's keep this under *D*.
I agree with dropping id from file and with the changed original definition..
I agree
I agree
Thanks I will add this to comment #124
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]