OASIS XML Localisation Interchange File Format (XLIFF) TC

Hi David, all, > *E)* > Value of optional id attributes is questionable > *Proposed change:* > Depending on the resolution of D above, make all ids required. > Complementary kill ids where they seem to be optional. To which comment this major change would corresponds too? Comment 121 (not listed in your enumeration) proposes this change for <segment> id only. In addition to <segment>, id is currently optional in: <file>, <group>, <ignorable> and <note>. I think you also forgot to list the arguments supporting the statement "Value of optional id attributes is questionable". Could you elaborate and give examples? -yves

Hello 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 mailto: david.filip@ul.ie On Tue, Oct 22, 2013 at 6:49 PM, Yves Savourel < ysavourel@enlaso.com > wrote: Hi David, all, > *E)* > Value of optional id attributes is questionable > *Proposed change:* > Depending on the resolution of D above, make all ids required. > Complementary kill ids where they seem to be optional. To which comment this major change would corresponds too? Comment 121 (not listed in your enumeration) proposes this change for <segment> id only. 121 is only about typos, required id for segment is requested in #111  In addition to <segment>, id is currently optional in: <file>, <group>, <ignorable> and <note>. I believe that all of these should have either required id or no id at all. It is true that the comment 111 only requests required ids on segments, another comment in csprd01 requested required ids on match. This is becuase these comments were coming mitivated by a particular implementation issue. Yet I think that we can generalized that the value of optional ids is dubious.. If the resolution for the issue *D* decides that unit ids need to be unique within file and not parent, than eventually group ids could become optional..  I think you also forgot to list the arguments supporting the statement "Value of optional id attributes is questionable". I belive that it is questionable becuase you cannot rely on the id being there, so that you cannot count on referencing ids as a general implementation principle, referncing then seems only possible locally and not in e.g. DB representations..  Could you elaborate and give examples? -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, >> In addition to <segment>, id is currently optional in: >> <file>, <group>, <ignorable> and <note>. > > I believe that all of these should have either required id > or no id at all. > ... > If the resolution for the issue *D* decides that unit ids need > to be unique within file and not parent, than eventually group > ids could become optional..  Why? I don't think the two issues/solutions are related. When unit's ids are only unique per parent the tools needing unique values have to create their own but they don't need group ids for that. >> I think you also forgot to list the arguments supporting the statement >> "Value of optional id attributes is questionable". > > I belive that it is questionable becuase you cannot rely on the id being > there, so that you cannot count on referencing ids as a general implementation > principle, referncing then seems only possible locally and not > in e.g. DB representations.. That sounds like a processing-side argument :) XLIFF is an interchange format: and nothing prevent an optional IDs to be there if it is needed. Some implementation don't use IDs to associate (for example) a segment with a match, but they would generate the IDs on output (like Okapi does). As for implementations that use IDs (like some DB-based one) nothing prevent them to create those id when they do their processing (or when reading the document) and output them alter on. Note that I'm not especially against a required id for <segment> (it can be used for many things), but as you can see in the previous paragraph, the case for optional can be made even for <segment> (and the referencing still work). So don't think it should be mandatory nor forbidden on <group>, <ignorable> and <note>. Cheers, -yves

Thanks, Yves, I think I see a consensus looming.. I do not think that my argument is driven by using XLIFF as a processing format, rather by processing XLIFF as an interchange format, which are totally different things. And I believe that the TC agreed that 2.0 is a roundtrip exchange format rather the old fire and die interchange format, so having (relatively) stable (actually as stable as possible) ids for the whole roundtrip at least on the key structural elements seems desirable. 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. 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*. 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 Tue, Oct 22, 2013 at 9:51 PM, Yves Savourel < ysavourel@enlaso.com > wrote: Hi David, all, >> In addition to <segment>, id is currently optional in: >> <file>, <group>, <ignorable> and <note>. > > I believe that all of these should have either required id > or no id at all. > ... > If the resolution for the issue *D* decides that unit ids need > to be unique within file and not parent, than eventually group > ids could become optional..  Why? I don't think the two issues/solutions are related. When unit's ids are only unique per parent the tools needing unique values have to create their own but they don't need group ids for that. >> I think you also forgot to list the arguments supporting the statement >> "Value of optional id attributes is questionable". > > I belive that it is questionable becuase you cannot rely on the id being > there, so that you cannot count on referencing ids as a general implementation > principle, referncing then seems only possible locally and not > in e.g. DB representations.. That sounds like a processing-side argument :) XLIFF is an interchange format: and nothing prevent an optional IDs to be there if it is needed. Some implementation don't use IDs to associate (for example) a segment with a match, but they would generate the IDs on output (like Okapi does). As for implementations that use IDs (like some DB-based one) nothing prevent them to create those id when they do their processing (or when reading the document) and output them alter on. Note that I'm not especially against a required id for <segment> (it can be used for many things), but as you can see in the previous paragraph, the case for optional can be made even for <segment> (and the referencing still work). So don't think it should be mandatory nor forbidden on <group>, <ignorable> and <note>. Cheers, -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, > 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. > 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, 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." So we would have: - Required id on: <segment> (changed from optional) - Optional id on: <group>, <note>, <ignorable> (no change) - No id on <file> (changed from optional) 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. -yves

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,   > 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?   Yes.   The general case for both <ec> and <em> is that these elements indicate closing of paired codes or annotations. So are associated with the same ID value as their corresponding opening part. The rational to use startRef was (I think) that it is a reference to an ID rather than the ID itself.   Only when <ec> is isolated (i.e. its opening part is not in the same <unit>) the element uses the id attribute. The rational in that case is that since it has no element to refer it shouldn’t use startRef.   For <em>, as you noted, the specification does not allow for annotations across units, so startRef can always be used and therefore the id attribute is not needed.   -yves