OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xliff-inline message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]