Re: [xliff-inline] Semantics for canReorder editing hint

["Dr. David Filip" <David.Filip@ul.ie>]

Hi Fredrik, Yves,

 

I’m leaning towards the most permissive model where the canReorder property only apply to the order among the elements that set it to “no”. The rational for my thinking here is that it allows an implementation that need the stricter variant to get it by setting canReoder=”no” on all tags. If we mandate the strictest interpretation we do not give implementations the choice of a relaxed version.

I fully agree with the above reasoning for  relaxed/permissive semantics

But it would not allow representing the following two cases

* Having two inline codes nested inside the same parent and allowing them to be re-ordered inside the parent but not moved outside it.

* Having two parents with nested content in the same segment that can be re-ordered but the contents of the parent elements must stay with its respective parent.

IMHO we must not overload the "canreorder" with this. If this has sufficecent business case (read occurs  frequently enough that it is worth handling, and I am not sure about that). Proper handling should be with a spearate atribute "mustnotleaveparent". 

This tiogether with canreoder would give the desired set of bhaviors..

But the question is are there examples where something needs to leave a parent? So does it need explicit handling at all?

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

mailto: david.filip@ul.ie

On Wed, Mar 7, 2012 at 10:19, Estreen, Fredrik <Fredrik.Estreen@lionbridge.com> wrote:

Hi Yves, all,

 

I think we need to either define how the attribute works or consider removing it. Having a feature with only undefined behavior feels wrong to me. 

 

These rules would handle cases where you have an inline code that is nested inside another inline code and must not be moved to a different nest level or outside its current parent. That would be done by setting canReorder to “no” on both the code and parent code.

  

I think it is ok to not allow these operations in the processing expectations. I see the processing expectations more as a baseline where we specify the set of operations that should be guaranteed to work and provide interoperability if all implementations follow them. If an application goes outside of the expectations and that breaks another applications it is clear who is at fault. It also allows making implementations that can be run in “safe” or “unsafe” mode depending on what other implementations they expect to interoperate with. Perhaps this last point is more appropriate for the TC at large.

 

Regards,

Fredrik Estreen

 

From: xliff-inline@lists.oasis-open.org [mailto:xliff-inline@lists.oasis-open.org] On Behalf Of Yves Savourel
Sent: den 25 februari 2012 23:47
To: xliff-inline@lists.oasis-open.org
Subject: RE: [xliff-inline] Semantics for canReorder editing hint

 

Hi Fredrik, all,

 

The more I’m looking at the possibilities for assigning processing expectations to canReorder, the more it seems difficult. Either they’ll be too simple and prevent tools to do what they should be able to do, or they’ll be too complicated to implement reasonably.

 

I wonder if this is a case where XLIFF could just pass information and not assign specific processing expectation? That wouldn’t be good for interoperability obviously, but then, as you pointed out, they are different ways to look at canReorder, and I’m not sure if choosing one would really serve interoperable any way.

 

-ys

 

 

From: xliff-inline@lists.oasis-open.org [mailto:xliff-inline@lists.oasis-open.org] On Behalf Of Estreen, Fredrik
Sent: Wednesday, February 22, 2012 6:49 AM
To: xliff-inline@lists.oasis-open.org
Subject: [xliff-inline] Semantics for canReorder editing hint

 

Hi All,

 

While trying to write up a summary of processing expectations for editing segment content with inline tags I started thinking about the hint on re-ordering the inline codes. And after looking at a few potential cases I’m starting to wonder what the semantics for the canReorder property should be.

 

The strictest interpretation would imply that if ONE attribute has canReorder=”no” you can obviously not reorder it with respect to other inline codes or change its nesting. But further you would not be allowed to clone it so it would imply canCopy=”no”. Probably it should also imply that it is not removable. But I think it would also mean that you could not clone or remove any inline code in the segment.

 

I’m using simplified tags in the examples to keep them more compact in some cases.

 

This <ph id=”1” nid =”n1” />is <ph id=”2” nid =”n2” canReorder=”no”>the <ph id=”3” nid =”n3” /> example.

 

If we allow cloning and removal of the two unconstrained tags we implicitly allow re-ordering them with respect to the middle tag:

 

Operation 1 adds: This <ph id=”1” nid =”n1” /><ph id=”5” nid =”n3” />is <ph id=”2” nid =”n2” canReorder=”no”>the <ph id=”3” nid =”n3” /><ph id=”4” nid =”n1” /> example.

 

Operation 2 removes: This <ph id=”5” nid =”n3” />is <ph id=”2” nid =”n2” canReorder=”no”>the <ph id=”4” nid =”n1” /> example.

 

Besides using new ID values the underlying native code is identical to just swapping the tags in one operation.

 

If we allow removal and copying of the tags that cannot be reordered the same problem arise:

 

Operation 1 adds: <ph id=”4” nid =”n2” canReorder=”no”>This <ph id=”1” nid =”n1” />is <ph id=”2” nid =”n2” canReorder=”no”>the <ph id=”3” nid =”n3” /> example.

 

Operation 2 removes: <ph id=”4” nid =”n2” canReorder=”no”>This <ph id=”1” nid =”n1” />is the <ph id=”3” nid =”n3” /> example.

 

 

Is reordering of tags allowed as long as they do not change what side or nest level of the tag with the reordering flag set they appear at? So that this is allowed:

Start: <pc id=”1”>This</pc> <pc id=”2”>is</pc> <ph id=”3” canReorder=”no” /> <pc id=”4”>the</pc> <pc id=”5”>example</pc>.

Result: <pc id=”2”>This</pc> <pc id=”1”>is</pc> <ph id=”3” canReorder=”no” /> <pc id=”5”>the</pc> <pc id=”4”>example</pc>.

 

But this is not allowed:

Start: <pc id=”1”>This</pc> <pc id=”2”>is</pc> <ph id=”3” canReorder=”no” /> <pc id=”4”>the</pc> <pc id=”5”>example</pc>.

Result: <pc id=”4”>This</pc> <pc id=”5”>is</pc> <ph id=”3” canReorder=”no” /> <pc id=”1”>the</pc> <pc id=”2”>example</pc>.

 

One could argue that any change to the rest of the tags like reordering, adding and removing would change the total ordering with respect to the tag with the reordering flag set. If we take that position it would be more useful to have the ordering constraint as an attribute on the segment instead of on the tag. I feel this would might be too strict for many use cases and formats.

 

The most permissive interpretation would be that the ordering is only relevant among the set of tags that have reordering restricted and all changes to unconstrained tags are allowed.

 

Besides these there are many more areas that are interesting in this, including nesting and with it cloning of parents or children of tags that cannot be reordered.

 

I’m not sure yet what semantics I would prefer. I’m leaning towards the most strict interpretation as it would be the one leading to the least number of interoperability issues if applied. But it will also lead to a quite restricted editing experience for users, but that is perhaps what you want when you use this constraint. The alternative for me is to go with the most permissive interpretation and put the burden on the extraction tool if the stricter model is wanted. It can do this by setting all tags to not allow copying, deleting or reordering.­

 

Any ideas, comments or suggestions on this is appreciated.

 

Regards,

Fredrik Estreen