OASIS XML Localisation Interchange File Format (XLIFF) TC

Author: DavidFilip Date: 2016-09-26 16:59:29 +0000 (Mon, 26 Sep 2016) New Revision: 699 Web View: https://tools.oasis-open.org/version-control/browse/wsvn/xliff/?rev=699&sc=1 Modified: trunk/xliff-21/elements/change-tracking/item.xml Log: <ctr:item> prose strawman to see what can be done in xsd and what needs to go to sch

Hi all, So, looking at the proposal for <item> in CTR, we would have: [[ item Container for a specific revision associated with a sibling element, or a child of a sibling element, to the change track module within the scope of the enclosing element. Either: one or more <segment> or <ignorable> elements in any order. Or: either: exactly one <source> element followed by at most one <target> element. or: exactly one <target> element. Or: XLIFF Core Inline Elements and text in any order. ]] A few initial notes: I'm not sure that mixing four different content models in the same element is a good idea. Parsing such content, even with automated mechanism like JAXB, is not easy. I'm also not sure why we would need the second and third content (<source> and <source>+<target>) since they can be represented by the first and fourth content. I'm also not understanding the definition part that says: "...to the change track module within the scope of the enclosing element." What the "to" pertains to? It seems something is missing (or extra). -ys

Thanks, Yves, all
I am adding the XLIFF comment list into the loop to allow Chase to chime in

quick answers inline



> [[
> item
>
> Container for a specific revision associated with a sibling element, or a
> child of a sibling element, to the change track module within the scope of
> the enclosing element.
>
> Either:
> one or more <segment> or <ignorable> elements in any order.
> Or:
> either:
> exactly one element followed by at most one
> <target> element.
> or:
> exactly one <target> element.
> Or:
> XLIFF Core Inline Elements and text in any order.
> ]]
>
> A few initial notes:
>
> I'm not sure that mixing four different content models in the same element
> is a good idea.
> Parsing such content, even with automated mechanism like JAXB, is not easy.
>

I was thinking about having different item types, but that would probably
not improve things either
In the old XLIFF 1.2 days having source and target was just enough to
repeat the <trans-unit> model but it's not enough for 2.x

>
> I'm also not sure why we would need the second and third content (
> and +<target>) since they can be represented by the first and
> fourth content.
>
The simplest thing would be to allow just the 1st content, since everything
is covered by the <unit> data model
But I understand that people want the liberty to track smaller parts
I think that the most common tracking use case would be for target only, at
least based on what Chase said in the OMOS TC today

>
> I'm also not understanding the definition part that says: "...to the
> change track module within the scope of the enclosing element."
> What the "to" pertains to? It seems something is missing (or extra).
>
Yes, this is garbled, trying to reword the scoping verbiage throughout the
ctr elements..


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

Thanks, Yves, all I am adding the XLIFF comment list into the loop to allow Chase to chime in quick answers inline [[ item Container for a specific revision associated with a sibling element, or a child of a sibling element, to the change track module within the scope of the enclosing element. Either:         one or more <segment> or <ignorable> elements in any order. Or:         either:                 exactly one <source> element followed by at most one <target> element.         or:                 exactly one <target> element. Or:         XLIFF Core Inline Elements and text in any order. ]] A few initial notes: I'm not sure that mixing four different content models in the same element is a good idea. Parsing such content, even with automated mechanism like JAXB, is not easy. I was thinking about having different item types, but that would probably not improve things either  In the old XLIFF 1.2 days having source and target was just enough to repeat the <trans-unit> model but it's not enough for 2.x I'm also not sure why we would need the second and third content (<source> and <source>+<target>) since they can be represented by the first and fourth content. The simplest thing would be to allow just the 1st content, since everything is covered by the <unit> data model But I understand that people want the liberty to track smaller parts I think that the most common tracking use case would be for target only, at least based on what Chase said in the OMOS TC today I'm also not understanding the definition part that says: "...to the change track module within the scope of the enclosing element." What the "to" pertains to? It seems something is missing (or extra). Yes, this is garbled, trying to reword the scoping verbiage throughout the ctr elements..    -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

Hi David, all,



It seems to me the CTR module is becoming rather complicated.

Here are a few things I've noted after a quick look at the latest draft:





=== Issues ===



--- Do we really want to allow agents to track the content of individual inline codes?

That can be done by tracking the parent's content itself (in a much simpler way).





--- You can have revisions that apply to different elements but be inconsistent:



For example, you can have:



<revisions appliesTo="target">

...

</revisions>

<revisions appliesTo="segment">

...

</revisions>



With both tracking the same content (since segment is a superset of target), but there are no way to safely make sense of their history (e.g. datetime is optional so one may not now the order of the changes, the currentVersion of each could be contradictory, etc.) It'd be impossible to really use across different tools, which make the existence of a common module pointless.

The same issue arises with revisions on specific inline codes along with revisions on the source/target content.



One of the things we wanted to achieve with XLIFF 2.x is avoid having different ways to do the same thing. CTR2.1 has many ways to do the same thing.





--- Currently a <revision> can have more than 1 <item> with the same property value. Which means you can have N different changes for the same data at the same time.





--- I'm unsure how attributes work in the case of tracking a segment/ignorable content.



For example, you may have a revision of the state attribute of the segment s1, but have also an item tracking the segments for the unit where that segment s1 is in; and that segment may have a different state. When a tool looks for the history of the state values for s1 what does it do? Look just at the revisions for appliesTo='target' + property='state' or also take into account the state attribute in the item for appliesTo='segment' + property='content'?





--- Having <originalData> inside <item> seems a bad idea: the content of <item> should be same content as /<target>/<segment/etc. It should probably be at the <revision> level.





=== Thoughts ===



Some ideas:



- Make datetime a required attribute. A history without date/time is a lot less useful, and datetime is easy to set for any tool.





- Get rid of currentVersion: If "the most current version of a revision" means "the latest", then a required datetime takes care of this, without having to maintain an extra attribute (and a bunch of PRs). Or maybe I'm missing the point of this attribute.





- Let's not allow to track individual inline codes. I don't think anyone has made that requirement. It would also make things complicated for interoperability since you would have different ways to track them (individually or in content).





- Add a constraint saying the property values of <item> must be unique within a given <revision>.





- It seems we are having too many ways to track the same thing. And/or we try to do too much.



The only obstacle, as far as know, that prevent us to use inline in <item> is that we say must have its corresponding <sm/>.

But maybe we've been focusing too much (once again) on the XLIFF markup.



The more general issue with content in CTR entries is that we take it out of context (from a markup viewpoint). But the actual data after parsing is what we really need to store. So, if we have this:



<target>...data text</target>



We can store it like this:



<item property='content'><mrk id='m1' translate='no'>...data</mrk> text<item>



The other aspect of CTR is that I don't think we can expect all the constraints the normal unit content has to apply in the CTR elements. We will have duplicate ID values, etc.





- As far as the different types of <item> content: I'm not sure we need all the possibilities the draft currently has. Do we have requirements for all of them?





Cheers,

-yves

Hi Yves,

thanks for this, this is really helpful. I am too worried about the CTRM
becoming too complicated. As I said in the last meeting this is intended as
a strawman that puts forward an array of possible solutions, happy to
restrict them along the lines you suggested..

I introduced the simpleItem in the latest draft and that was inspired by
the use cases as described by Chase in the XLIFF OMOS call last week..
I think that the biggest issue the design needs to solve is that CTRM
doesn't have control over the XLIFF Core content, therefore storing small
changes with small footprint is always in danger of becoming useless when
the core is modified by an Agent unaware of CTRM..

So I heard two conflicting requirements:
1) Let me store small changes with a small footprint, I don't want to store
the whole segment if I made a tiny text change or similar
2) Don't let things get stored in different ways in CTRM

I am reacting to some specifics of you feedback inline below..
On Monday, I will create another version of the CTRM 2.1 proposal based on
this feedback and the reflections I expressed here and inline below..

Cheers and thanks
dF

Dr. David Filip
===========
OASIS XLIFF OMOS TC Chair
OASIS XLIFF TC Secretary, Editor, Liaison Officer
Spokes Research Fellow
ADAPT Centre
KDEG, Trinity College Dublin
Mobile: +420-777-218-122


On Sun, Oct 2, 2016 at 3:54 AM, Yves <yves@opentag.com> wrote:

> Hi David, all,
>
>
>
> It seems to me the CTR module is becoming rather complicated.
>
> Here are a few things I've noted after a quick look at the latest draft:
>
>
>
>
>
> === Issues ===
>
>
>
> --- Do we really want to allow agents to track the content of individual
> inline codes?
>
> That can be done by tracking the parent's content itself (in a much
> simpler way).
>
>
>
dF: As I said above I am happy not to track individual inlines, but
tracking structural parents will bring lot of unwanted redundancy

>
>
> --- You can have revisions that apply to different elements but be
> inconsistent:
>
>
>
> For example, you can have:
>
>
>
> <revisions appliesTo="target">
>
> ...
>
> </revisions>
>
> <revisions appliesTo="segment">
>
> ...
>
> </revisions>
>
>
>
> With both tracking the same content (since segment is a superset of
> target), but there are no way to safely make sense of their history (e.g.
> datetime is optional so one may not now the order of the changes, the
> currentVersion of each could be contradictory, etc.) It'd be impossible to
> really use across different tools, which make the existence of a common
> module pointless.
>
> The same issue arises with revisions on specific inline codes along with
> revisions on the source/target content.
>
>
>
> One of the things we wanted to achieve with XLIFF 2.x is avoid having
> different ways to do the same thing. CTR2.1 has many ways to do the same
> thing.
>
>
>
>
>
> --- Currently a <revision> can have more than 1 <item> with the same
> property value. Which means you can have N different changes for the same
> data at the same time.
>

Good catch, happy to put a uniqueness requirement (Constraint) on that.

>
>
>
>
> --- I'm unsure how attributes work in the case of tracking a
> segment/ignorable content.
>
>
>
> For example, you may have a revision of the state attribute of the segment
> s1, but have also an item tracking the segments for the unit where that
> segment s1 is in; and that segment may have a different state. When a tool
> looks for the history of the state values for s1 what does it do? Look just
> at the revisions for appliesTo='target' + property='state' or also take
> into account the state attribute in the item for appliesTo='segment' +
> property='content'?
>
>
>
>
>
> --- Having <originalData> inside <item> seems a bad idea: the content of
> <item> should be same content as /<target>/<segment/etc. It
> should probably be at the <revision> level.
>
Ok, to have them at <revision>
I thought that the highest possible level of item was the same as unit, but
you're right that <item> is complicated enough w/o original data..


>
>
>
>
> === Thoughts ===
>
>
>
> Some ideas:
>
>
>
> - Make datetime a required attribute. A history without date/time is a lot
> less useful, and datetime is easy to set for any tool.
>
+1 to that

>
>
>
>
> - Get rid of currentVersion: If "the most current version of a revision"
> means "the latest", then a required datetime takes care of this, without
> having to maintain an extra attribute (and a bunch of PRs). Or maybe I'm
> missing the point of this attribute.
>
Fine with me, little value in those extra PRs and the REQUIRED datetime
attribute is more reliable

>
>
>
>
> - Let's not allow to track individual inline codes. I don't think anyone
> has made that requirement. It would also make things complicated for
> interoperability since you would have different ways to track them
> (individually or in content).
>
Again, fine with me, I just want to highlight that the current draft
version is a restriction compared with the 2.0 ctr where you can track ANY
XLIFF defined element

I am happy to take out the individual codes from the enumeration of the
trackable elements..
Again, I just want to make everyone aware that it will require larger
portions of text stored as revisions even in case of minor changes..


>
>
>
> - Add a constraint saying the property values of <item> must be unique
> within a given <revision>.
>
+1

>
>
>
>
> - It seems we are having too many ways to track the same thing. And/or we
> try to do too much.
>
>
>
> The only obstacle, as far as know, that prevent us to use inline in <item>
> is that we say must have its corresponding <sm/>.
>
> But maybe we've been focusing too much (once again) on the XLIFF markup.
>
>
>
> The more general issue with content in CTR entries is that we take it out
> of context (from a markup viewpoint). But the actual data after parsing is
> what we really need to store. So, if we have this:
>
>
>
> <target>...data text</target>
>
>
>
> We can store it like this:
>
>
>
> <item property='content'><mrk id='m1' translate='no'>...data</mrk>
> text<item>
>
I don't think this is a good idea, the stuff between start of <target> and
the unhandled isolated is actually text too and not untranslatable
data. Remember we store data in <originalData> and we don't allow to store
mix them with inline content..

>
>
> The other aspect of CTR is that I don't think we can expect all the
> constraints the normal unit content has to apply in the CTR elements. We
> will have duplicate ID values, etc.
>
I think you can have unit like identity constraints on item and probably
within each <revision> elements. As discussed before, the module uniqueness
scope is separate from the core <unit> uniqueness scope.. Not sure which of
the above you mean?

>
>
>
>
> - As far as the different types of <item> content: I'm not sure we need
> all the possibilities the draft currently has. Do we have requirements for
> all of them?
>
I think that theere are only two clear requirements
Tracking simple target revisions
and note changes
I am sure there would be value in tracking of segmentation changes

The Ocelot requirements seem to be informed by the XLIFF 1.2 usage of
<alt-trans> for <trans-unit><target> changes
In 1.2 the <alt-trans> has two allowed data types, the full <trans-unit>
and <target> only.

Since <unit> is our logical unit in 2.0, and its data model is more
complicated than <trans-unit> because it handles segmentation too. I think
we don't really have an option.
I tried to cater for simple needs with the simplified <simpleItem> that
would basically only allow for one type of the 4 types of <item> content.


>
>
>
>
> Cheers,
>
> -yves
>
>
>
>
>

Hi Yves, thanks for this, this is really helpful. I am too worried about the CTRM becoming too complicated. As I said in the last meeting this is intended as a strawman that puts forward an array of possible solutions, happy to restrict them along the lines you suggested..  I introduced the simpleItem in the latest draft and that was inspired by the use cases as described by Chase in the XLIFF OMOS call last week.. I think that the biggest issue the design needs to solve is that CTRM doesn't have control over the XLIFF Core content, therefore storing small changes with small footprint is always in danger of becoming useless when the core is modified by an Agent unaware of CTRM.. So I heard two conflicting requirements: 1) Let me store small changes with a small footprint, I don't want to store the whole segment if I made a tiny text change or similar 2) Don't let things get stored in different ways in CTRM I am reacting to some specifics of you feedback inline below..  On Monday, I will create another version of the CTRM 2.1 proposal based on this feedback and the reflections I expressed here and inline below.. Cheers and thanks dF Dr. David Filip =========== OASIS XLIFF OMOS TC Chair OASIS XLIFF TC Secretary, Editor, Liaison Officer Spokes Research Fellow ADAPT Centre KDEG, Trinity College Dublin Mobile: +420-777-218-122 On Sun, Oct 2, 2016 at 3:54 AM, Yves < yves@opentag.com > wrote: Hi David, all,   It seems to me the CTR module is becoming rather complicated. Here are a few things I've noted after a quick look at the latest draft:     === Issues ===   --- Do we really want to allow agents to track the content of individual inline codes? That can be done by tracking the parent's content itself (in a much simpler way).   dF: As I said above I am happy not to track individual inlines, but tracking structural parents will bring lot of unwanted redundancy    --- You can have revisions that apply to different elements but be inconsistent:   For example, you can have:   <revisions appliesTo="target"> ... </revisions> <revisions appliesTo="segment"> ... </revisions>   With both tracking the same content (since segment is a superset of target), but there are no way to safely make sense of their history (e.g. datetime is optional so one may not now the order of the changes, the currentVersion of each could be contradictory, etc.) It'd be impossible to really use across different tools, which make the existence of a common module pointless. The same issue arises with revisions on specific inline codes along with revisions on the source/target content.   One of the things we wanted to achieve with XLIFF 2.x is avoid having different ways to do the same thing. CTR2.1 has many ways to do the same thing.     --- Currently a <revision> can have more than 1 <item> with the same property value. Which means you can have N different changes for the same data at the same time. Good catch, happy to put a uniqueness requirement (Constraint) on that.      --- I'm unsure how attributes work in the case of tracking a segment/ignorable content.   For example, you may have a revision of the state attribute of the segment s1, but have also an item tracking the segments for the unit where that segment s1 is in; and that segment may have a different state. When a tool looks for the history of the state values for s1 what does it do? Look just at the revisions for appliesTo='target' + property='state' or also take into account the state attribute in the item for appliesTo='segment' + property='content'?     --- Having <originalData> inside <item> seems a bad idea: the content of <item> should be same content as <source>/<target>/<segment/ etc. It should probably be at the <revision> level. Ok, to have them at <revision> I thought that the highest possible level of item was the same as unit, but you're right that <item> is complicated enough w/o original data..       === Thoughts ===   Some ideas:   - Make datetime a required attribute. A history without date/time is a lot less useful, and datetime is easy to set for any tool. +1 to that      - Get rid of currentVersion: If "the most current version of a revision" means "the latest", then a required datetime takes care of this, without having to maintain an extra attribute (and a bunch of PRs). Or maybe I'm missing the point of this attribute. Fine with me, little value in those extra PRs and the REQUIRED datetime attribute is more reliable      - Let's not allow to track individual inline codes. I don't think anyone has made that requirement. It would also make things complicated for interoperability since you would have different ways to track them (individually or in content). Again, fine with me, I just want to highlight that the current draft version is a restriction compared with the 2.0 ctr where you can track ANY XLIFF defined element I am happy to take out the individual codes from the enumeration of the trackable elements.. Again, I just want to make everyone aware that it will require larger portions of text stored as revisions even in case of minor changes..     - Add a constraint saying the property values of <item> must be unique within a given <revision>. +1      - It seems we are having too many ways to track the same thing. And/or we try to do too much.   The only obstacle, as far as know, that prevent us to use inline in <item> is that we say <em/> must have its corresponding <sm/>. But maybe we've been focusing too much (once again) on the XLIFF markup.   The more general issue with content in CTR entries is that we take it out of context (from a markup viewpoint). But the actual data after parsing is what we really need to store. So, if we have this:      <target>...data<em startRef='m1'/> text</target>   We can store it like this:      <item property='content'><mrk id='m1' translate='no'>...data</mrk> text<item> I don't think this is a good idea, the stuff between start of <target> and the unhandled isolated <em/> is actually text too and not untranslatable data. Remember we store data in <originalData> and we don't allow to store mix them with inline content..    The other aspect of CTR is that I don't think we can expect all the constraints the normal unit content has to apply in the CTR elements. We will have duplicate ID values, etc. I think you can have unit like identity constraints on item and probably within each <revision> elements. As discussed before, the module uniqueness scope is separate from the core <unit> uniqueness scope.. Not sure which of the above you mean?      - As far as the different types of <item> content: I'm not sure we need all the possibilities the draft currently has. Do we have requirements for all of them? I think that theere are only two clear requirements Tracking simple target revisions and note changes I am sure there would be value in tracking of segmentation changes  The Ocelot requirements seem to be informed by the XLIFF 1.2 usage of <alt-trans> for <trans-unit><target> changes In 1.2 the <alt-trans> has two allowed data types, the full <trans-unit> and <target> only. Since <unit> is our logical unit in 2.0, and its data model is more complicated than <trans-unit> because it handles segmentation too. I think we don't really have an option.  I tried to cater for simple needs with the simplified <simpleItem> that would basically only allow for one type of the 4 types of <item> content.         Cheers, -yves    

Hi Yves, all, just to look a bit more what was done on CTRM today:

<orginalData> moved onto <revision>

On Sun, Oct 2, 2016 at 3:54 AM, Yves <yves@opentag.com> wrote:

> - Make datetime a required attribute. A history without date/time is a lot
> less useful, and datetime is easy to set for any tool.
>
DONE

>
>
> - Get rid of currentVersion: If "the most current version of a revision"
> means "the latest", then a required datetime takes care of this, without
> having to maintain an extra attribute (and a bunch of PRs). Or maybe I'm
> missing the point of this attribute.
>
DONE

>
>
> - Let's not allow to track individual inline codes. I don't think anyone
> has made that requirement. It would also make things complicated for
> interoperability since you would have different ways to track them
> (individually or in content).
>
DONE

>
>
> - Add a constraint saying the property values of <item> must be unique
> within a given <revision>.
>
DONE

>
>
>
>
> - It seems we are having too many ways to track the same thing. And/or we
> try to do too much.
>
I think this is now well addressed. It defines Content Types A, B, C, and D

A is needed to track unit content
B or C is needed to track segment or ignorable content
D is enough to track source, target, note and attributes
Additionally, inlines are prohibited when tracking note or attributes

The content level is really given by not having unhandled orphaned codes.

Cheers and thanks
dF


Dr. David Filip
===========
OASIS XLIFF OMOS TC Chair
OASIS XLIFF TC Secretary, Editor, Liaison Officer
Spokes Research Fellow
ADAPT Centre
KDEG, Trinity College Dublin
Mobile: +420-777-218-122

Hi Yves, all, just to look a bit more what was done on CTRM today: <orginalData> moved onto <revision> On Sun, Oct 2, 2016 at 3:54 AM, Yves < yves@opentag.com > wrote: - Make datetime a required attribute. A history without date/time is a lot less useful, and datetime is easy to set for any tool. DONE     - Get rid of currentVersion: If "the most current version of a revision" means "the latest", then a required datetime takes care of this, without having to maintain an extra attribute (and a bunch of PRs). Or maybe I'm missing the point of this attribute. DONE     - Let's not allow to track individual inline codes. I don't think anyone has made that requirement. It would also make things complicated for interoperability since you would have different ways to track them (individually or in content). DONE     - Add a constraint saying the property values of <item> must be unique within a given <revision>. DONE      - It seems we are having too many ways to track the same thing. And/or we try to do too much. I think this is now well addressed. It defines Content Types A, B, C, and D A is needed to track unit content B or C is needed to track segment or ignorable content D is enough to track source, target, note and attributes Additionally, inlines are prohibited when tracking note or attributes The content level is really given by not having unhandled orphaned codes.  Cheers and thanks dF  Dr. David Filip =========== OASIS XLIFF OMOS TC Chair OASIS XLIFF TC Secretary, Editor, Liaison Officer Spokes Research Fellow ADAPT Centre KDEG, Trinity College Dublin Mobile: +420-777-218-122