OASIS XML Localisation Interchange File Format (XLIFF) TC

  • 1.  Modules attributes in ec vs em

    Posted 12-07-2013 20:55
    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


  • 2.  RE: [xliff] Modules attributes in ec vs em

    Posted 12-08-2013 17:07
    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 [xliff@lists.oasis-open.org] on behalf of Yves Savourel [ysavourel@enlaso.com] Sent: Saturday, December 07, 2013 12:54 PM To: 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


  • 3.  RE: [xliff] Modules attributes in ec vs em

    Posted 12-09-2013 02:24
    To be more specific on the SLR attributes. Currently the specifications say: On <pc> and <sc>: - storageRestriction - sizeRestriction - equivStorage - sizeInfo - sizeInfoRef On <ec>: - equivStorage - sizeInfo - sizeInfoRef On <mrk> and <sm>: - storageRestriction - sizeRestriction On <em>: None Looking more closely at the definition now, I think it makes sense. But, Fredrik, it would be good if you could confirm that it is the expected list. Thanks. -ys
    Original Message


  • 4.  RE: [xliff] Modules attributes in ec vs em

    Posted 12-09-2013 20:55
    Hi Yves, all, Yes, the equivStorage, sizeInfo and sizeInfoRef are allowed on the <ec> element, but only if the <ec> also has isolated set to yes. The rational is that we need a way to represent the size of the <ec> when it is not paired with a <sc>. And since an isolated <ec> cannot be converted to a <pc> we do not need additional processing requirements when converting a <sc>,<ec> pair into a <pc>. The isolated requirement is in the module specification text. Regards, Fredrik Estreen >
    Original Message


  • 5.  RE: [xliff] Modules attributes in ec vs em

    Posted 12-09-2013 21:09
    Just reading this... This answer some of the questions I just posted. > since an isolated <ec> cannot be converted to a <pc> Good point (I think). But the <pc> to isolated <sc>/<ec> case needs to be module/extension agnostic otherwise tools not implementing SLR won't do it. Cheers, -ys
    Original Message


  • 6.  Re: [xliff] Modules attributes in ec vs em

    Posted 12-09-2013 21:41
    On Mon, Dec 9, 2013 at 9:08 PM, Yves Savourel < ysavourel@enlaso.com > wrote: But the <pc> to isolated <sc>/<ec> case needs to be module/extension agnostic otherwise tools not implementing SLR won't do it. But there is no way to convert a <pc> into sc and ec with isolated. The resulting pair will be always in thw same unit The only valid way to become isolated is being so extracted IMHO 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


  • 7.  RE: [xliff] Modules attributes in ec vs em

    Posted 12-10-2013 03:52
    Hi David, all, > But there is no way to convert a <pc> into sc and ec with isolated. > The resulting pair will be always in the same unit I'm not so sure we can be so absolute. A tool could for example use a fragment of a translated content to create a match entry for another one and create an isolated <ec> in the process. And I'm pretty sure tools and people will find other creative ways to end up with isolated codes. Currently he tools handle such situation for the modules/extensions attributes they don't support as they wish. And maybe that's good enough. BTW, if FS can be only on isolated <ec> like the SLR attributes, maybe we need to say so it the specification. Cheers, -ys


  • 8.  Re: [xliff] Modules attributes in ec vs em

    Posted 12-10-2013 09:57
    Yves, all 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, Dec 10, 2013 at 3:51 AM, Yves Savourel < ysavourel@enlaso.com > wrote: Hi David, all, > But there is no way to convert a <pc> into sc and ec with isolated. > The resulting pair will be always in the same unit I'm not so sure we can be so absolute. A tool could for example use a fragment of a translated content to create a match entry for another one and create an isolated <ec> in the process. This can happen only in matches module, so we can say that in matches module the data can be dropped, and say so in the matches module  And I'm pretty sure tools and people will find other creative ways to end up with isolated codes. In this case and in the case of joining multiple file elements that were not extracted together, and in any other case we cannot possibly handle all what can be done to the files if people do not stick to the allowed transformations specified regrouping units or files are not allowed transformations, whereas re-segmenting is and it is out of scope to say what happens if people decide to do not allowed transformations. If they decide to do it let them do it privately and no one cares if they undo it before sending the payload further or back. Currently he tools handle such situation for the modules/extensions attributes they don't support as they wish. And maybe that's good enough. I agree there must be summary PRs for handling module attributes on codes and module and extended attributes on markers. I just do not agree that these should cover not allowed operations such as making an isolated code out of a <pc>, changing file, group and unit structure etc. If we describe such handling it will appear lenient and will encourage the illegal behavior  BTW, if FS can be only on isolated <ec> like the SLR attributes, maybe we need to say so it the specification. I agree  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


  • 9.  Re: [xliff] Modules attributes in ec vs em

    Posted 12-09-2013 10:07
    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 On Sun, Dec 8, 2013 at 5:06 PM, Schnabel, Bryan S < 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 [ xliff@lists.oasis-open.org ] on behalf of Yves Savourel [ ysavourel@enlaso.com ] Sent: Saturday, December 07, 2013 12:54 PM To: 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


  • 10.  RE: [xliff] Modules attributes in ec vs em

    Posted 12-09-2013 15:04
    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


  • 11.  RE: [xliff] Modules attributes in ec vs em

    Posted 12-09-2013 21:06
    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


Related Content