XLIFF Inline Markup SC

 View Only
  • 1.  [xliff-inline] Semantics for canReorder editing hint

    Posted 02-22-2012 13:51
    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


  • 2.  RE: [xliff-inline] Semantics for canReorder editing hint

    Posted 02-22-2012 16:27
    Hi Fredrik, all, Thanks for going through that exercise. There are indeed different ways to look at this. One additional aspect: Maybe the reordering needs to be looked at from the <unit> level rather than the <segment> as segmentation may change. For example: If you have original a single segment for the unit, then split it into two and have a code with canReorder='no' in the second segment, adding a code in the first segment has ultimately the same effect as adding it in the segment where the code with canReorder='no' is since the merging tool would merge back the unit as a whole. As for which interpretation to select: I'll need to think more about it to have a meaningful opinion. Cheers, -yves 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


  • 3.  RE: [xliff-inline] Semantics for canReorder editing hint

    Posted 02-25-2012 22:47
    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


  • 4.  RE: [xliff-inline] Semantics for canReorder editing hint

    Posted 03-07-2012 10:21




    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. 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.
     
    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.
     
    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.
     
    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






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

    Posted 03-07-2012 13:06
    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