[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xliff] Modules attributes in ec vs em
Hi Bryan, David, all, Looking closer to this: -- There are no processing requirements about what an agent need to do when it goes from <pc> to <sc>/<ec> or from <mrk> to <sm>/<em> with regard to modules/extensions attributes. Which means we can go from: <pc id='1' fs:fs='b' my:attr='value'>text</pc> To: <sc id='1' fs:fs='b' my:attr='value'/>text<ec startRef='1'/> And obviously the same for isolated . One doesn't need to copy any info to <em> because, as David pointed out, we'll always have the corresponding <sm> in the unit. But the case of <ec> is less clear. The SLR has details about that, allowing the attributes in <ec> only for the isolated cases. (BTW: it'd be good to have that text in Constraints or PR sections, or at least have a 'MUST' somewhere: otherwise it's easy to miss). The problem here is that it won't work if the agent doesn't supports SLR. We need blanket processing requirements that covers all modules/extensions. That could go in the "4.7.2.2 Usage of <pc> and <sc>/<ec>" section. Maybe it can be: An agent going from <pc> to <sc>/<ec> MUST include the modules/extensions attributes in <ec> only if it is an isolated one. -- Different values in <sc> and <ec> The reverse operation is also possible (going from <sc>/<ec> to <pc>. What happens with attributes if the same exists in both starting and ending elements but do not have the same value? One has to take precedence (presumably the one in <sc>?) Cheers, -yves -----Original Message----- From: Schnabel, Bryan S [mailto:bryan.s.schnabel@tektronix.com] Sent: Monday, December 9, 2013 8:04 AM To: Dr. David Filip Cc: Yves Savourel; xliff@lists.oasis-open.org Subject: RE: [xliff] Modules attributes in ec vs em David, I do not feel strongly one way or the other WRT <ec>. I simply could not think of a use case for allowing it. But if you could present a use case I might better understand. Thanks, Bryan ________________________________ From: Dr. David Filip [David.Filip@ul.ie] Sent: Monday, December 09, 2013 2:06 AM To: Schnabel, Bryan S Cc: Yves Savourel; xliff@lists.oasis-open.org Subject: Re: [xliff] Modules attributes in ec vs em I think that this distribution has the same logic as the distribution of refs and ids While an orphaned <ec/> can exist in a unit, orphaned <em/> is not allowed and MUST NOT appear. So the logic IMHO is that you might need to associate fs or slr info with orphaned ecs and that is why they are allowed But no need for having it on <em/> because you'll always have a corresponding <sm/> for placing it. So I do not agree with Bryan that fs should be taken down from <ec/> Rgds 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<mailto:david.filip@ul.ie> On Sun, Dec 8, 2013 at 5:06 PM, Schnabel, Bryan S <bryan.s.schnabel@tektronix.com<mailto:bryan.s.schnabel@tektronix.com>> wrote: I think we should take @fs and @subFs off of <ec>. Cannot comment on SLR yet. I am working on some SLR use case and I must say I'm getting pretty excited about the module in general (sorry for this general statement of support for SLR which does not have any bearing on this thread). ________________________________________ From: xliff@lists.oasis-open.org<mailto:xliff@lists.oasis-open.org> [xliff@lists.oasis-open.org<mailto:xliff@lists.oasis-open.org>] on behalf of Yves Savourel [ysavourel@enlaso.com<mailto:ysavourel@enlaso.com>] Sent: Saturday, December 07, 2013 12:54 PM To: xliff@lists.oasis-open.org<mailto:xliff@lists.oasis-open.org> Subject: [xliff] Modules attributes in ec vs em Hi Bryan, Fredrik, all While working on the validation I've noticed that we have the attributes for the FS and the SLR modules allowed in <sc> and <ec>, but only in <sm> not in <em>. Is that normal? 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 --------------------------------------------------------------------- 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]