RE: [xliff] Modules attributes in ec vs em

[Yves Savourel <ysavourel@enlaso.com>]

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