OASIS XML Localisation Interchange File Format (XLIFF) TC

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 For <file> I would propose to drop the id attribute, and have original as the way to identify the resource corresponding to the given <file> (which is already its role). I would also update the definition of 'original' from: "Original file - a pointer to the location of the original document from which the content of the enclosing <file> element is extracted." To: "Original resource - a IRI identifying the original resource from which the content of the <file> element is extracted." 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? So we would have: - Required id on: <segment> (changed from optional) 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.. - Optional id on: <group>, <note>, <ignorable> (no change) - No id on <file> (changed from 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 http://www.cngl.ie/profile/?i=452 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, > This said I would be happy with markers, <segment>, <unit>, > <group>, and <file> ids being compulsory > while <note> and <ignorable> being optional. > > Having marker ids always compulsory would simplify the current > notation dependent constraints, also marker ids became critical > after prohibiting metadata on segment. 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 > Group ids can be optional if unit ids are required to be > unique within file rather than parent, I do see this as > an important interrelation with the issue *D*. I cannot see the relation between having unit ids unique per file and having id optional on groups, BUT since I do think having unit ids unique per file is needed, Let's keep this under *D*.  that makes my puzzlement moot and we don't have to discuss it. That leaves <file>. And for that one I tend to think id is not needed. First there is the 'original' attribute that seems to fill the same role (and is older: <file> has no id in 1.2). Also: several <file> elements can be moved to a single XLIFF documents, for example when bundling a package. Several tools have even utilities to do this. In such case you may have clash of identical IDs and you are left with two options: a) not bundle one of the <file> or b) change its ID value; none of which is really doable. For <file> I would propose to drop the id attribute, and have original as the way to identify the resource corresponding to the given <file> (which is already its role). I would also update the definition of 'original' from: "Original file - a pointer to the location of the original document from which the content of the enclosing <file> element is extracted." To: "Original resource - a IRI identifying the original resource from which the content of the <file> element is extracted." I agree with dropping id from file and with the changed original definition.. So we would have: - Required id on: <segment> (changed from optional) I agree  - Optional id on: <group>, <note>, <ignorable> (no change) - No id on <file> (changed from optional) I agree  BTW: One more correction for the spec: in the section 2.3.1 in the list of attribute the link on the 'original' attribute points to the section for the 'name' attribute instead of the section for the 'original' attribute. Thanks I will add this to comment #124  -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

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 http://www.cngl.ie/profile/?i=452 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 For <file> I would propose to drop the id attribute, and have original as the way to identify the resource corresponding to the given <file> (which is already its role). I would also update the definition of 'original' from: "Original file - a pointer to the location of the original document from which the content of the enclosing <file> element is extracted." To: "Original resource - a IRI identifying the original resource from which the content of the <file> element is extracted." 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? So we would have: - Required id on: <segment> (changed from optional) 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.. - Optional id on: <group>, <note>, <ignorable> (no change) - No id on <file> (changed from 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 http://www.cngl.ie/profile/?i=452 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, > This said I would be happy with markers, <segment>, <unit>, > <group>, and <file> ids being compulsory > while <note> and <ignorable> being optional. > > Having marker ids always compulsory would simplify the current > notation dependent constraints, also marker ids became critical > after prohibiting metadata on segment. 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 > Group ids can be optional if unit ids are required to be > unique within file rather than parent, I do see this as > an important interrelation with the issue *D*. I cannot see the relation between having unit ids unique per file and having id optional on groups, BUT since I do think having unit ids unique per file is needed, Let's keep this under *D*.  that makes my puzzlement moot and we don't have to discuss it. That leaves <file>. And for that one I tend to think id is not needed. First there is the 'original' attribute that seems to fill the same role (and is older: <file> has no id in 1.2). Also: several <file> elements can be moved to a single XLIFF documents, for example when bundling a package. Several tools have even utilities to do this. In such case you may have clash of identical IDs and you are left with two options: a) not bundle one of the <file> or b) change its ID value; none of which is really doable. For <file> I would propose to drop the id attribute, and have original as the way to identify the resource corresponding to the given <file> (which is already its role). I would also update the definition of 'original' from: "Original file - a pointer to the location of the original document from which the content of the enclosing <file> element is extracted." To: "Original resource - a IRI identifying the original resource from which the content of the <file> element is extracted." I agree with dropping id from file and with the changed original definition.. So we would have: - Required id on: <segment> (changed from optional) I agree  - Optional id on: <group>, <note>, <ignorable> (no change) - No id on <file> (changed from optional) I agree  BTW: One more correction for the spec: in the section 2.3.1 in the list of attribute the link on the 'original' attribute points to the section for the 'name' attribute instead of the section for the 'original' attribute. Thanks I will add this to comment #124  -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

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] Sent: Thursday, November 14, 2013 7:25 AM To: Dr. David Filip Cc: Yves Savourel; xliff@lists.oasis-open.org Subject: Re: [xliff] IDs - Optional attributes (E)   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 http://www.cngl.ie/profile/?i=452 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   For <file> I would propose to drop the id attribute, and have original as the way to identify the resource corresponding to the given <file> (which is already its role). I would also update the definition of 'original' from: "Original file - a pointer to the location of the original document from which the content of the enclosing <file> element is extracted." To: "Original resource - a IRI identifying the original resource from which the content of the <file> element is extracted."   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? So we would have: - Required id on: <segment> (changed from optional) 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..   - Optional id on: <group>, <note>, <ignorable> (no change) - No id on <file> (changed from 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 http://www.cngl.ie/profile/?i=452 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, > This said I would be happy with markers, <segment>, <unit>, > <group>, and <file> ids being compulsory > while <note> and <ignorable> being optional. > > Having marker ids always compulsory would simplify the current > notation dependent constraints, also marker ids became critical > after prohibiting metadata on segment. 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 > Group ids can be optional if unit ids are required to be > unique within file rather than parent, I do see this as > an important interrelation with the issue *D*. I cannot see the relation between having unit ids unique per file and having id optional on groups, BUT since I do think having unit ids unique per file is needed, Let's keep this under *D*.  that makes my puzzlement moot and we don't have to discuss it. That leaves <file>. And for that one I tend to think id is not needed. First there is the 'original' attribute that seems to fill the same role (and is older: <file> has no id in 1.2). Also: several <file> elements can be moved to a single XLIFF documents, for example when bundling a package. Several tools have even utilities to do this. In such case you may have clash of identical IDs and you are left with two options: a) not bundle one of the <file> or b) change its ID value; none of which is really doable. For <file> I would propose to drop the id attribute, and have original as the way to identify the resource corresponding to the given <file> (which is already its role). I would also update the definition of 'original' from: "Original file - a pointer to the location of the original document from which the content of the enclosing <file> element is extracted." To: "Original resource - a IRI identifying the original resource from which the content of the <file> element is extracted."   I agree with dropping id from file and with the changed original definition.. So we would have: - Required id on: <segment> (changed from optional) I agree  - Optional id on: <group>, <note>, <ignorable> (no change) - No id on <file> (changed from optional) I agree  BTW: One more correction for the spec: in the section 2.3.1 in the list of attribute the link on the 'original' attribute points to the section for the 'name' attribute instead of the section for the 'original' attribute. Thanks I will add this to comment #124  -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      

Hi Yves, I still agree that id is not needed when original is provided, but original is optional, so I have suggested in the above  to either 1) make original REQUIRED  or 2) make one of original or id REQUIRED Since I did not hear opinions on that option I proposed the latter as the solution, as it seem to give more flexibility to extractors 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 http://www.cngl.ie/profile/?i=452 mailto: david.filip@ul.ie On Thu, Nov 14, 2013 at 3:04 PM, Yves Savourel < ysavourel@enlaso.com > wrote: 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 ] Sent: Thursday, November 14, 2013 7:25 AM To: Dr. David Filip Cc: Yves Savourel; xliff@lists.oasis-open.org Subject: Re: [xliff] IDs - Optional attributes (E)   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 http://www.cngl.ie/profile/?i=452 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   For <file> I would propose to drop the id attribute, and have original as the way to identify the resource corresponding to the given <file> (which is already its role). I would also update the definition of 'original' from: "Original file - a pointer to the location of the original document from which the content of the enclosing <file> element is extracted." To: "Original resource - a IRI identifying the original resource from which the content of the <file> element is extracted."   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? So we would have: - Required id on: <segment> (changed from optional) 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..   - Optional id on: <group>, <note>, <ignorable> (no change) - No id on <file> (changed from 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 http://www.cngl.ie/profile/?i=452 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, > This said I would be happy with markers, <segment>, <unit>, > <group>, and <file> ids being compulsory > while <note> and <ignorable> being optional. > > Having marker ids always compulsory would simplify the current > notation dependent constraints, also marker ids became critical > after prohibiting metadata on segment. 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 > Group ids can be optional if unit ids are required to be > unique within file rather than parent, I do see this as > an important interrelation with the issue *D*. I cannot see the relation between having unit ids unique per file and having id optional on groups, BUT since I do think having unit ids unique per file is needed, Let's keep this under *D*.  that makes my puzzlement moot and we don't have to discuss it. That leaves <file>. And for that one I tend to think id is not needed. First there is the 'original' attribute that seems to fill the same role (and is older: <file> has no id in 1.2). Also: several <file> elements can be moved to a single XLIFF documents, for example when bundling a package. Several tools have even utilities to do this. In such case you may have clash of identical IDs and you are left with two options: a) not bundle one of the <file> or b) change its ID value; none of which is really doable. For <file> I would propose to drop the id attribute, and have original as the way to identify the resource corresponding to the given <file> (which is already its role). I would also update the definition of 'original' from: "Original file - a pointer to the location of the original document from which the content of the enclosing <file> element is extracted." To: "Original resource - a IRI identifying the original resource from which the content of the <file> element is extracted."   I agree with dropping id from file and with the changed original definition.. So we would have: - Required id on: <segment> (changed from optional) I agree  - Optional id on: <group>, <note>, <ignorable> (no change) - No id on <file> (changed from optional) I agree  BTW: One more correction for the spec: in the section 2.3.1 in the list of attribute the link on the 'original' attribute points to the section for the 'name' attribute instead of the section for the 'original' attribute. Thanks I will add this to comment #124  -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      

Hi David, all, Actually, I really think all those ID spaces questions (including the (C) case) need to be addressed along with the URI issue I was mentioning here: https://lists.oasis-open.org/archives/xliff/201311/msg00054.html To summarize: If I have: <mrk id='m1' type='my:type' ref='#id1'>...</mrk> How does an application resolve the reference to "#id1"? The base resource of this URI is the document where the pointer is. But the fragment identifier may not be resolvable. Two <group>, <unit>, <segment>, etc. in different <file>, <unit>, etc. may have that same ID value. I think we have to devise a URI fragment identification mechanism for the XLIFF 2.0 media type. BTW: It is obvious to me that we are lagging behind in implementations. Many of those issues/questions I'm running into would have been raised before if anyone had implemented a Modifier agent. This doesn't bode well for the statements of uses. Cheers, -ys From: Dr. David Filip [ mailto:David.Filip@ul.ie ] Sent: Thursday, November 14, 2013 9:12 AM To: Yves Savourel Cc: Dr. David Filip; xliff@lists.oasis-open.org Subject: Re: [xliff] IDs - Optional attributes (E) Hi Yves, I still agree that id is not needed when original is provided, but original is optional, so I have suggested in the above to either 1) make original REQUIRED or 2) make one of original or id REQUIRED Since I did not hear opinions on that option I proposed the latter as the solution, as it seem to give more flexibility to extractors 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 http://www.cngl.ie/profile/?i=452 mailto: david.filip@ul.ie On Thu, Nov 14, 2013 at 3:04 PM, Yves Savourel <ysavourel@enlaso.com> wrote: 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 ] Sent: Thursday, November 14, 2013 7:25 AM To: Dr. David Filip Cc: Yves Savourel; xliff@lists.oasis-open.org Subject: Re: [xliff] IDs - Optional attributes (E) 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 http://www.cngl.ie/profile/?i=452 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 For <file> I would propose to drop the id attribute, and have original as the way to identify the resource corresponding to the given <file> (which is already its role). I would also update the definition of 'original' from: "Original file - a pointer to the location of the original document from which the content of the enclosing <file> element is extracted." To: "Original resource - a IRI identifying the original resource from which the content of the <file> element is extracted." 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? So we would have: - Required id on: <segment> (changed from optional) 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.. - Optional id on: <group>, <note>, <ignorable> (no change) - No id on <file> (changed from 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 http://www.cngl.ie/profile/?i=452 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, > This said I would be happy with markers, <segment>, <unit>, > <group>, and <file> ids being compulsory > while <note> and <ignorable> being optional. > > Having marker ids always compulsory would simplify the current > notation dependent constraints, also marker ids became critical > after prohibiting metadata on segment. 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 > Group ids can be optional if unit ids are required to be > unique within file rather than parent, I do see this as > an important interrelation with the issue *D*. I cannot see the relation between having unit ids unique per file and having id optional on groups, BUT since I do think having unit ids unique per file is needed, Let's keep this under *D*. that makes my puzzlement moot and we don't have to discuss it. That leaves <file>. And for that one I tend to think id is not needed. First there is the 'original' attribute that seems to fill the same role (and is older: <file> has no id in 1.2). Also: several <file> elements can be moved to a single XLIFF documents, for example when bundling a package. Several tools have even utilities to do this. In such case you may have clash of identical IDs and you are left with two options: a) not bundle one of the <file> or b) change its ID value; none of which is really doable. For <file> I would propose to drop the id attribute, and have original as the way to identify the resource corresponding to the given <file> (which is already its role). I would also update the definition of 'original' from: "Original file - a pointer to the location of the original document from which the content of the enclosing <file> element is extracted." To: "Original resource - a IRI identifying the original resource from which the content of the <file> element is extracted." I agree with dropping id from file and with the changed original definition.. So we would have: - Required id on: <segment> (changed from optional) I agree - Optional id on: <group>, <note>, <ignorable> (no change) - No id on <file> (changed from optional) I agree BTW: One more correction for the spec: in the section 2.3.1 in the list of attribute the link on the 'original' attribute points to the section for the 'name' attribute instead of the section for the 'original' attribute. Thanks I will add this to comment #124 -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

Yves, I am aware of the connection. I think that we will be able to have a very easy fragment identifying mechanism if we agree that an xliff document has 2 id scopes A 1) file 2) unit and that all id bearing elements within those 2 separate scopes share one id space per scope In case we kept id on file, the id scopes could be B 1) xliff 2) unit Based on the above, I now think that it is actually better to have required original and no id on a file rather than at least one required out of optional original or id, so that we can go with the A solution for id scopes 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 http://www.cngl.ie/profile/?i=452 mailto: david.filip@ul.ie On Thu, Nov 14, 2013 at 4:43 PM, Yves Savourel < ysavourel@enlaso.com > wrote: Hi David, all, Actually, I really think all those ID spaces questions (including the (C) case) need to be addressed along with the URI issue I was mentioning here: https://lists.oasis-open.org/archives/xliff/201311/msg00054.html To summarize: If I have: <mrk id='m1' type='my:type' ref='#id1'>...</mrk> How does an application resolve the reference to "#id1"? The base resource of this URI is the document where the pointer is. But the fragment identifier may not be resolvable. Two <group>, <unit>, <segment>, etc. in different <file>, <unit>, etc. may have that same ID value. I think we have to devise a URI fragment identification mechanism for the XLIFF 2.0 media type. BTW: It is obvious to me that we are lagging behind in implementations. Many of those issues/questions I'm running into would have been raised before if anyone had implemented a Modifier agent. This doesn't bode well for the statements of uses. Cheers, -ys From: Dr. David Filip [mailto: David.Filip@ul.ie ] Sent: Thursday, November 14, 2013 9:12 AM To: Yves Savourel Cc: Dr. David Filip; xliff@lists.oasis-open.org Subject: Re: [xliff] IDs - Optional attributes (E) Hi Yves, I still agree that id is not needed when original is provided, but original is optional, so I have suggested in the above  to either 1) make original REQUIRED  or 2) make one of original or id REQUIRED Since I did not hear opinions on that option I proposed the latter as the solution, as it seem to give more flexibility to extractors 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 http://www.cngl.ie/profile/?i=452 mailto: david.filip@ul.ie On Thu, Nov 14, 2013 at 3:04 PM, Yves Savourel < ysavourel@enlaso.com > wrote: 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 ] Sent: Thursday, November 14, 2013 7:25 AM To: Dr. David Filip Cc: Yves Savourel; xliff@lists.oasis-open.org Subject: Re: [xliff] IDs - Optional attributes (E) 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 http://www.cngl.ie/profile/?i=452 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 For <file> I would propose to drop the id attribute, and have original as the way to identify the resource corresponding to the given <file> (which is already its role). I would also update the definition of 'original' from: "Original file - a pointer to the location of the original document from which the content of the enclosing <file> element is extracted." To: "Original resource - a IRI identifying the original resource from which the content of the <file> element is extracted." 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? So we would have: - Required id on: <segment> (changed from optional) 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.. - Optional id on: <group>, <note>, <ignorable> (no change) - No id on <file> (changed from 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 http://www.cngl.ie/profile/?i=452 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, > This said I would be happy with markers, <segment>, <unit>, > <group>, and <file> ids being compulsory > while <note> and <ignorable> being optional. > > Having marker ids always compulsory would simplify the current > notation dependent constraints, also marker ids became critical > after prohibiting metadata on segment. 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 > Group ids can be optional if unit ids are required to be > unique within file rather than parent, I do see this as > an important interrelation with the issue *D*. I cannot see the relation between having unit ids unique per file and having id optional on groups, BUT since I do think having unit ids unique per file is needed, Let's keep this under *D*. that makes my puzzlement moot and we don't have to discuss it. That leaves <file>. And for that one I tend to think id is not needed. First there is the 'original' attribute that seems to fill the same role (and is older: <file> has no id in 1.2). Also: several <file> elements can be moved to a single XLIFF documents, for example when bundling a package. Several tools have even utilities to do this. In such case you may have clash of identical IDs and you are left with two options: a) not bundle one of the <file> or b) change its ID value; none of which is really doable. For <file> I would propose to drop the id attribute, and have original as the way to identify the resource corresponding to the given <file> (which is already its role). I would also update the definition of 'original' from: "Original file - a pointer to the location of the original document from which the content of the enclosing <file> element is extracted." To: "Original resource - a IRI identifying the original resource from which the content of the <file> element is extracted." I agree with dropping id from file and with the changed original definition.. So we would have: - Required id on: <segment> (changed from optional) I agree - Optional id on: <group>, <note>, <ignorable> (no change) - No id on <file> (changed from optional) I agree BTW: One more correction for the spec: in the section 2.3.1 in the list of attribute the link on the 'original' attribute points to the section for the 'name' attribute instead of the section for the 'original' attribute. Thanks I will add this to comment #124 -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 --------------------------------------------------------------------- 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

I don’t see how that can work. -- First option B cannot work: We can't have a xliff-level scope has the <file> inside may vary during the process (bundling files) (at least that is something tools have been offering for 1.2 and I don't think we can go away from that). -- As for option A, I still don't see how you would resolve "myDoc.xlf#id1" on the following myDoc.xlf document: <xliff xmlns="urn:oasis:names:tc:xliff:document:2.0" version="2.0" srcLang="en" trgLang="fr"> <file origin="f1"> <unit id="id1"> <segment id="id1"> <source>source</source> <target>target</target> </segment> </unit> </file> <file origin="f2"> <unit id="id1"> <segment id="id1"> <source>source</source> <target>target</target> </segment> </unit> </file> </xliff> -ys From: Dr. David Filip [ mailto:David.Filip@ul.ie ] Sent: Thursday, November 14, 2013 11:28 AM To: Yves Savourel Cc: xliff@lists.oasis-open.org Subject: Re: [xliff] IDs - Optional attributes (E) Yves, I am aware of the connection. I think that we will be able to have a very easy fragment identifying mechanism if we agree that an xliff document has 2 id scopes A 1) file 2) unit and that all id bearing elements within those 2 separate scopes share one id space per scope In case we kept id on file, the id scopes could be B 1) xliff 2) unit Based on the above, I now think that it is actually better to have required original and no id on a file rather than at least one required out of optional original or id, so that we can go with the A solution for id scopes 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 http://www.cngl.ie/profile/?i=452 mailto: david.filip@ul.ie On Thu, Nov 14, 2013 at 4:43 PM, Yves Savourel <ysavourel@enlaso.com> wrote: Hi David, all, Actually, I really think all those ID spaces questions (including the (C) case) need to be addressed along with the URI issue I was mentioning here: https://lists.oasis-open.org/archives/xliff/201311/msg00054.html To summarize: If I have: <mrk id='m1' type='my:type' ref='#id1'>...</mrk> How does an application resolve the reference to "#id1"? The base resource of this URI is the document where the pointer is. But the fragment identifier may not be resolvable. Two <group>, <unit>, <segment>, etc. in different <file>, <unit>, etc. may have that same ID value. I think we have to devise a URI fragment identification mechanism for the XLIFF 2.0 media type. BTW: It is obvious to me that we are lagging behind in implementations. Many of those issues/questions I'm running into would have been raised before if anyone had implemented a Modifier agent. This doesn't bode well for the statements of uses. Cheers, -ys From: Dr. David Filip [ mailto:David.Filip@ul.ie ] Sent: Thursday, November 14, 2013 9:12 AM To: Yves Savourel Cc: Dr. David Filip; xliff@lists.oasis-open.org Subject: Re: [xliff] IDs - Optional attributes (E) Hi Yves, I still agree that id is not needed when original is provided, but original is optional, so I have suggested in the above to either 1) make original REQUIRED or 2) make one of original or id REQUIRED Since I did not hear opinions on that option I proposed the latter as the solution, as it seem to give more flexibility to extractors 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 http://www.cngl.ie/profile/?i=452 mailto: david.filip@ul.ie On Thu, Nov 14, 2013 at 3:04 PM, Yves Savourel <ysavourel@enlaso.com> wrote: 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 ] Sent: Thursday, November 14, 2013 7:25 AM To: Dr. David Filip Cc: Yves Savourel; xliff@lists.oasis-open.org Subject: Re: [xliff] IDs - Optional attributes (E) 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 http://www.cngl.ie/profile/?i=452 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 For <file> I would propose to drop the id attribute, and have original as the way to identify the resource corresponding to the given <file> (which is already its role). I would also update the definition of 'original' from: "Original file - a pointer to the location of the original document from which the content of the enclosing <file> element is extracted." To: "Original resource - a IRI identifying the original resource from which the content of the <file> element is extracted." 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? So we would have: - Required id on: <segment> (changed from optional) 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.. - Optional id on: <group>, <note>, <ignorable> (no change) - No id on <file> (changed from 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 http://www.cngl.ie/profile/?i=452 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, > This said I would be happy with markers, <segment>, <unit>, > <group>, and <file> ids being compulsory > while <note> and <ignorable> being optional. > > Having marker ids always compulsory would simplify the current > notation dependent constraints, also marker ids became critical > after prohibiting metadata on segment. 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 > Group ids can be optional if unit ids are required to be > unique within file rather than parent, I do see this as > an important interrelation with the issue *D*. I cannot see the relation between having unit ids unique per file and having id optional on groups, BUT since I do think having unit ids unique per file is needed, Let's keep this under *D*. that makes my puzzlement moot and we don't have to discuss it. That leaves <file>. And for that one I tend to think id is not needed. First there is the 'original' attribute that seems to fill the same role (and is older: <file> has no id in 1.2). Also: several <file> elements can be moved to a single XLIFF documents, for example when bundling a package. Several tools have even utilities to do this. In such case you may have clash of identical IDs and you are left with two options: a) not bundle one of the <file> or b) change its ID value; none of which is really doable. For <file> I would propose to drop the id attribute, and have original as the way to identify the resource corresponding to the given <file> (which is already its role). I would also update the definition of 'original' from: "Original file - a pointer to the location of the original document from which the content of the enclosing <file> element is extracted." To: "Original resource - a IRI identifying the original resource from which the content of the <file> element is extracted." I agree with dropping id from file and with the changed original definition.. So we would have: - Required id on: <segment> (changed from optional) I agree - Optional id on: <group>, <note>, <ignorable> (no change) - No id on <file> (changed from optional) I agree BTW: One more correction for the spec: in the section 2.3.1 in the list of attribute the link on the 'original' attribute points to the section for the 'name' attribute instead of the section for the 'original' attribute. Thanks I will add this to comment #124 -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 --------------------------------------------------------------------- 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

Thanks, Yves, I think that we are mixing two features here 1) Internal referencing This one should be OK if you use the two proposed internal scopes 2) external fragment referencing I believe that it is a new feature request. IMHO this may be included in the spec but may as well be only specified in the MIME type submission that I plan to make as soon as we progress to CS01. For external referencing, having an identifier on <file> is necessary. That is why I said that file should have id OR original REQUIRED If we put a uniqueness requirement on the original we will have a good external fragment identification mechanism. In the mechanism I envisage this URI  myDoc.xlf#id1 would FAIL as an external fragment identifier for the example file below. However myDoc.xlf#f1#id1 would externaly identify the only unit of the first file and e.g. this myDoc.xlf#f2#id1#id1 would identify the only segment of the second file *Yves file example:* <xliff xmlns="urn:oasis:names:tc: xliff:document:2.0" version="2.0" srcLang="en" trgLang="fr">  <file origin="f1">   <unit id="id1">    <segment id="id1">     <source>source</source>     <target>target</target>    </segment>   </unit>  </file>  <file origin="f2">   <unit id="id1">    <segment id="id1">     <source>source</source>     <target>target</target>    </segment>   </unit>  </file> </xliff> *end of example*   Please note that this can work nicely if uniqueness of ids within the two internal core scopes is REQUIRED as discussed elsewhere. No mechanism of this type can work if file has an optional identifier only, no matter if id or original, as discussed elsewhere. We would need to devise a custom mechanism for referencing module data, if module data is to be externally referencable e.g.  e.g. myDoc.xlf#f2#id1#gls#g1 [Please note that we cannot use gls: because : is allowed in NMTOKENS] but internally I suppose, modules reference back to core rather than vice versa (this will also resolve the matches modules issue, but will need to be changed for glossary as well) Thoughts? 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 http://www.cngl.ie/profile/?i=452 mailto: david.filip@ul.ie On Thu, Nov 14, 2013 at 7:03 PM, Yves Savourel < ysavourel@enlaso.com > wrote: I don’t see how that can work. -- First option B cannot work: We can't have a xliff-level scope has the <file> inside may vary during the process (bundling files) (at least that is something tools have been offering for 1.2 and I don't think we can go away from that). -- As for option A, I still don't see how you would resolve "myDoc.xlf#id1" on the following myDoc.xlf document: <xliff xmlns="urn:oasis:names:tc:xliff:document:2.0" version="2.0" srcLang="en" trgLang="fr">  <file origin="f1">   <unit id="id1">    <segment id="id1">     <source>source</source>     <target>target</target>    </segment>   </unit>  </file>  <file origin="f2">   <unit id="id1">    <segment id="id1">     <source>source</source>     <target>target</target>    </segment>   </unit>  </file> </xliff> -ys From: Dr. David Filip [mailto: David.Filip@ul.ie ] Sent: Thursday, November 14, 2013 11:28 AM To: Yves Savourel Cc: xliff@lists.oasis-open.org Subject: Re: [xliff] IDs - Optional attributes (E) Yves, I am aware of the connection. I think that we will be able to have a very easy fragment identifying mechanism if we agree that an xliff document has 2 id scopes A 1) file 2) unit and that all id bearing elements within those 2 separate scopes share one id space per scope In case we kept id on file, the id scopes could be B 1) xliff 2) unit Based on the above, I now think that it is actually better to have required original and no id on a file rather than at least one required out of optional original or id, so that we can go with the A solution for id scopes 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 http://www.cngl.ie/profile/?i=452 mailto: david.filip@ul.ie On Thu, Nov 14, 2013 at 4:43 PM, Yves Savourel < ysavourel@enlaso.com > wrote: Hi David, all, Actually, I really think all those ID spaces questions (including the (C) case) need to be addressed along with the URI issue I was mentioning here: https://lists.oasis-open.org/archives/xliff/201311/msg00054.html To summarize: If I have: <mrk id='m1' type='my:type' ref='#id1'>...</mrk> How does an application resolve the reference to "#id1"? The base resource of this URI is the document where the pointer is. But the fragment identifier may not be resolvable. Two <group>, <unit>, <segment>, etc. in different <file>, <unit>, etc. may have that same ID value. I think we have to devise a URI fragment identification mechanism for the XLIFF 2.0 media type. BTW: It is obvious to me that we are lagging behind in implementations. Many of those issues/questions I'm running into would have been raised before if anyone had implemented a Modifier agent. This doesn't bode well for the statements of uses. Cheers, -ys From: Dr. David Filip [mailto: David.Filip@ul.ie ] Sent: Thursday, November 14, 2013 9:12 AM To: Yves Savourel Cc: Dr. David Filip; xliff@lists.oasis-open.org Subject: Re: [xliff] IDs - Optional attributes (E) Hi Yves, I still agree that id is not needed when original is provided, but original is optional, so I have suggested in the above  to either 1) make original REQUIRED  or 2) make one of original or id REQUIRED Since I did not hear opinions on that option I proposed the latter as the solution, as it seem to give more flexibility to extractors 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 http://www.cngl.ie/profile/?i=452 mailto: david.filip@ul.ie On Thu, Nov 14, 2013 at 3:04 PM, Yves Savourel < ysavourel@enlaso.com > wrote: 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 ] Sent: Thursday, November 14, 2013 7:25 AM To: Dr. David Filip Cc: Yves Savourel; xliff@lists.oasis-open.org Subject: Re: [xliff] IDs - Optional attributes (E) 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 http://www.cngl.ie/profile/?i=452 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 For <file> I would propose to drop the id attribute, and have original as the way to identify the resource corresponding to the given <file> (which is already its role). I would also update the definition of 'original' from: "Original file - a pointer to the location of the original document from which the content of the enclosing <file> element is extracted." To: "Original resource - a IRI identifying the original resource from which the content of the <file> element is extracted." 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? So we would have: - Required id on: <segment> (changed from optional) 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.. - Optional id on: <group>, <note>, <ignorable> (no change) - No id on <file> (changed from 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 http://www.cngl.ie/profile/?i=452 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, > This said I would be happy with markers, <segment>, <unit>, > <group>, and <file> ids being compulsory > while <note> and <ignorable> being optional. > > Having marker ids always compulsory would simplify the current > notation dependent constraints, also marker ids became critical > after prohibiting metadata on segment. 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 > Group ids can be optional if unit ids are required to be > unique within file rather than parent, I do see this as > an important interrelation with the issue *D*. I cannot see the relation between having unit ids unique per file and having id optional on groups, BUT since I do think having unit ids unique per file is needed, Let's keep this under *D*. that makes my puzzlement moot and we don't have to discuss it. That leaves <file>. And for that one I tend to think id is not needed. First there is the 'original' attribute that seems to fill the same role (and is older: <file> has no id in 1.2). Also: several <file> elements can be moved to a single XLIFF documents, for example when bundling a package. Several tools have even utilities to do this. In such case you may have clash of identical IDs and you are left with two options: a) not bundle one of the <file> or b) change its ID value; none of which is really doable. For <file> I would propose to drop the id attribute, and have original as the way to identify the resource corresponding to the given <file> (which is already its role). I would also update the definition of 'original' from: "Original file - a pointer to the location of the original document from which the content of the enclosing <file> element is extracted." To: "Original resource - a IRI identifying the original resource from which the content of the <file> element is extracted." I agree with dropping id from file and with the changed original definition.. So we would have: - Required id on: <segment> (changed from optional) I agree - Optional id on: <group>, <note>, <ignorable> (no change) - No id on <file> (changed from optional) I agree BTW: One more correction for the spec: in the section 2.3.1 in the list of attribute the link on the 'original' attribute points to the section for the 'name' attribute instead of the section for the 'original' attribute. Thanks I will add this to comment #124 -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 --------------------------------------------------------------------- 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 --------------------------------------------------------------------- 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

Hi David, all, > Thanks, Yves, I think that we are mixing two features here Not really. It's all about how to resolve a fragment identifier in XLIFF. Your outline is mostly what I had in mind as well. But with a few differences/issues: -- a) I would use / to separate the different IDs rather than # which may cause confusion or break implementations looking only at the last # to find a fragment identifier. myDoc.xlf#f1/id1 would point to the lone unit of the first file myDoc.xlf#f2/id1/id1 would point to the lone segment of the second file --b) identifying the file with the value of origin is a problem. It's value is an URI. I'm not sure it's a good idea to have a URI as a part of another URI. This would leave us with having both origin and id for <file>, and having id required. But we would have to make provision for what happened when a Modifier groups <file> in the same document. Maybe it's Ok to have the file ID be a UUID. Another option would be to come up with a non-URI value based on a required origin, like the hash code of the URI string. But that may be adding a lot of complexity. --c) Group ids vs unit ids. I really dislike having those two completely separate structures share the same value space for their IDs. It may be alas the only solution to address URI fragment resolution. --d) Segment ids and inline elements Ids: Same here, there is something wrong with those two different levels of structure sharing the same value space for their IDs. To me this seems to shows that segments should have been a special kind of inline annotations rather than a separate level of structure. It will probably come back to haunt us, but it's too late for such massive change. --d) relative URI (just the fragment) may be difficult to implement. Maybe there are ways to have defaults based on the location of the relative reference. I don't think having a bunch for ref="#f1/g3/note6" is going to be nice when you are working within the same unit. In my case I get a better sense of what's working or not when implementing things. --f) non-core IDs... No idea how to address that yet. Cheers, -ys

Thanks, Yves, inline 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 http://www.cngl.ie/profile/?i=452 mailto: david.filip@ul.ie On Tue, Nov 19, 2013 at 1:48 PM, Yves Savourel < ysavourel@enlaso.com > wrote: Hi David, all, > Thanks, Yves, I think that we are mixing two features here Not really. It's all about how to resolve a fragment identifier in XLIFF. Your outline is mostly what I had in mind as well. But with a few differences/issues: -- a) I would use / to separate the different IDs rather than # which may cause confusion or break implementations looking only at the last # to find a fragment identifier. myDoc.xlf#f1/id1 would point to the lone unit of the first file myDoc.xlf#f2/id1/id1 would point to the lone segment of the second file We discussed this internaly at LRC / seems confusing to me, becauase it is not really a directory using # as separator is OK, as it needs not be escaped.. --b) identifying the file with the value of origin is a problem. It's value is an URI. I'm not sure it's a good idea to have a URI as a part of another URI. Not nice but should work, the other option is required ids, see furtehr  This would leave us with having both origin and id for <file>, and having id required. But we would have to make provision for what happened when a Modifier groups <file> in the same document. Maybe it's Ok to have the file ID be a UUID. I agree, seems the cleanest solution..  Another option would be to come up with a non-URI value based on a required origin, like the hash code of the URI string. But that may be adding a lot of complexity. I agree this adds too much complexity to be worth considering..  --c) Group ids vs unit ids. I really dislike having those two completely separate structures share the same value space for their IDs. It may be alas the only solution to address URI fragment resolution. Yves, I argued for unit ids being only unique within parents and group ids required. If it was so, you would not need the same scope for them. As it stands, this is, alas :-), indeed the only solution..  --d) Segment ids and inline elements Ids: Same here, there is something wrong with those two different levels of structure sharing the same value space for their IDs. To me this seems to shows that segments should have been a special kind of inline annotations rather than a separate level of structure. It will probably come back to haunt us, but it's too late for such massive change. I agree that this cannot be changed. This is strictly analogical with the grouping. Yet, having only two internal id scopes has advatntages, so I am not especially unhappy about unit being a single uniqueness scope.. --d) relative URI (just the fragment) may be difficult to implement. Maybe there are ways to have defaults based on the location of the relative reference. I don't think having a bunch for ref="#f1/g3/note6" is going to be nice when you are working within the same unit. In my case I get a better sense of what's working or not when implementing things. I think that all internal referencing should be done using just #id. This will be unique within core due to the uniqueness constraints.  --f) non-core IDs... No idea how to address that yet. I believe there are two options, module prefixes as I suggested or UUIDs as in case of file  Cheers, -ys --------------------------------------------------------------------- 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

Hi all, Here are some thoughts about the XLIFF 2.0 URIs to continue the discussion on that topic. We have IDs in <file>, <group>, <unit>, <segment>/<ignorable>, <pc>/<sc>/<mrk>/<sm>, <note>, and <data>. - The IDs of <file> must be unique within the document. But with the caveat that additional <file> can be added to the document later on. This led us to tentatively say that maybe the file's id should be a UUID. Note that it's not that easy to implement, for example I don't think XSLT has a way to create UUIDs. It would have to rely on third-party extension for this. That may be the case in other programming languages. - The IDs of <group> must be unique within the <file> - The IDs of <unit> must be unique within the <file>. Those may or may not share the same ID scope as the groups. - The IDs of <note> must be unique within the <file> (<note> can be at the <file>, <group> or <unit> level). So creating a new note means using a UUID or knowing all notes' IDs in that given file. - The IDs for <segment>/<ignorable> must be unique within the <unit> - The IDs for <pc>/<ph>/<sc>/<mrk>/<sm> must be unique with the <unit> (with the source/target usual caveat). We have a tentative agreement that those elements could share the <segment>/<ignorable> IDs scope (I'll refer to it as "segOrInlineIDs") - The IDs for <data> must be unique within the <originalData> A few additional constraints: - Our "segOrInlineIDs" can be duplicated: one in the source the other in the target. The URI should be able to indicates which one it points to. - The Match module is bringing additional headache to the <unit>. A match has its own <source> and <target> and <data> elements. So we'll have to somehow distinguish them from the "main" ones. - Various modules (and obviously any extension) can use references as well. The Glossary is an example of this. Currently the definition of id for glossentry does not offer scope information ( http://docs.oasis-open.org/xliff/xliff-core/v2.0/xliff-core-v2.0.html#gls_id ). We'll have to resolve this somehow. === Using levels A first potential solution is the one David described: using a hierarchy of IDs with a separator. The separator is a separate question. It simply needs to be a character allowed in a URI but not allowed in an NMTOKEN. #, /, ~, etc. would work. We just have to pick one. I'll use / throughout this email. For example: #fileID/groupOrUnitID/segOrInlineID A first, and I think show-stopper, issue: The notes can appear at different levels so it's not really possible to use them in such hierarchy. === Using prefixes Another potential solution could be to use prefixes along with a more flexible hierarchy. For example: most IDs in the fragment would be represented like this: <prefixLetter>=IdValue f for files g for groups u for units n for notes d for data non-prefixed value would be the segOrInlineIDs For example: #f=550e8400-e29b-41d4-a716-446655440000/g=id1 -> the group id='id1' anywhere in the file id='550e8400-e29b-41d4-a716-446655440000' #f=550e8400-e29b-41d4-a716-446655440000/u=id1 -> the unit id='id1' anywhere in the file id='550e8400-e29b-41d4-a716-446655440000' #f=550e8400-e29b-41d4-a716-446655440000/n=id1 -> the note id='id1' anywhere in the file id='550e8400-e29b-41d4-a716-446655440000' #f=550e8400-e29b-41d4-a716-446655440000/u=u1/s1 -> the segment id='s1' in the unit id='u1' anywhere in the file id='550e8400-e29b-41d4-a716-446655440000' #f=550e8400-e29b-41d4-a716-446655440000/u=u1/m1 -> the annotation id='m1' in the unit id='u1' anywhere in the file id='550e8400-e29b-41d4-a716-446655440000' #f=550e8400-e29b-41d4-a716-446655440000/u=u1/1 -> the code id='1' in the unit id='u1' anywhere in the file id='550e8400-e29b-41d4-a716-446655440000' #f=550e8400-e29b-41d4-a716-446655440000/u=u1/d=d1 -> the data id='d1' in the unit id='u1' anywhere in the file id='550e8400-e29b-41d4-a716-446655440000' We could maybe resolve the source/target issue with an final '~s' and '~t' after the segorInlineID value. The ~ would allow to distinguish it from the ID value. For example: #f=550e8400-e29b-41d4-a716-446655440000/u=u1/m1~s -> the annotation id='m1' in the source content of the unit id='u1' anywhere in the file id='550e8400-e29b-41d4-a716-446655440000' #f=550e8400-e29b-41d4-a716-446655440000/u=u1/s1~t -> the target element in the segment id='s1' of the unit id='u1' anywhere in the file id='550e8400-e29b-41d4-a716-446655440000' You could even imagine this working for the unit: #f=550e8400-e29b-41d4-a716-446655440000/u=u1~t -> the whole target content of the unit id='u1' anywhere in the file id='550e8400-e29b-41d4-a716-446655440000'. Not sure if it's really useful or even needed, because it doesn't always correspond to a single physical element. Just a thought. So far it seems it would work. --- Now for relative fragment: We could imply any missing part by the location of the reference attribute. #n=n123 -> the note id='n123' in the current <file> #u=234/10~s -> the source inline code or segment/ignorable id='10' in the unit id='123' in the current file. We would have invalid values for the cases where the position of the reference attribute does not provide the proper context. For example: #10~s used at a group level would not be valid as there is no unit context. I think it would be relatively easy to implement for most applications. But the solution requires a relatively complex parsing of the fragment. Bryan will have to see if XSLT can support such mechanism. --- Modules Now there is the issue of the modules. A possible option is to require two things: - a) any ID in a module must be set using the attribute id in the module/extension namespace (An evensimpler alternative would be to require xml:id) - b) any ID value in a module to be a UUID We could then use a special prefix for it: #f=550e8400-e29b-41d4-a716-446655440000/m=47ab0064-d9d4-4ef9-9805-c3ad88f0bae6 -> the module/extended element id='47ab0064-d9d4-4ef9-9805-c3ad88f0bae6' anywhere in the file id=550e8400-e29b-41d4-a716-446655440000 This guaranties even the core can find such ID and it can be referenced uniquely within each file. That's not pretty and it comes with the issue of generating UUID for some programming languages. But I can't think of another solution so far. --- Matches The solution above still does not handle using <source>/<target>/<data> in matches. Technically you could have the same Ids used in the match elements and in the unit where these matches are. Still thinking... Cheers, -ys

One more thought: > - The IDs of <file> must be unique within the document. > ... > Note that UUIDs may not that easy to implement, for example > I don't think XSLT has a way to create UUIDs. If UUIDs are not a good choice for the file Id value, maybe it can be a URN instead. And then maybe we can go back to a single attribute origin=URN (instead of URI) to identify the file. The implementation could still use a UUID if it wants. -ys