[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xliff] IDs - Optional attributes (E)
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]