OASIS XML Localisation Interchange File Format (XLIFF) TC

 View Only
Expand all | Collapse all

XLIFF 2.0 Comments - B.1.3.7 subtype processing requirements

  • 1.  XLIFF 2.0 Comments - B.1.3.7 subtype processing requirements

    Posted 05-29-2013 08:06
    B.1.3.7 subtype processing requirements state:   If the attribute type is modified, the attribute subtype must be updated or deleted.   Is this always the case? What if I have a two types, e.g. “tm” and “mt”, that have the same subType? If my type changes from “tm” to “mt” there may be no reason for me to update or delete the subState. Was there a particular reason for this processing requirement? Similar sub attributes…   2.3.1.34 subType 2.3.1.35 subState D.1.2.2 subFs   …do not have this requirement.   Thanks, Ryan    


  • 2.  RE: [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype processing requirements

    Posted 05-29-2013 10:47
    I think this PR comes from the constraint that you should not have a subtype without a type, therefore the subtype is linked to the
    type (it complements it).

    In your example, if a type can have the same subtype value you can have an "invisible" update: the updated subtype value simply
    happens to have the same value as before.



    -ys



    From: Ryan King [mailto:ryanki@microsoft.com]
    Sent: Wednesday, May 29, 2013 2:05 AM
    To: xliff-comment@lists.oasis-open.org
    Cc: xliff@lists.oasis-open.org
    Subject: [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype processing requirements



    B.1.3.7 subtype processing requirements state:



    If the attribute type is modified, the attribute subtype must be updated or deleted.



    Is this always the case? What if I have a two types, e.g. "tm" and "mt", that have the same subType? If my type changes from "tm" to
    "mt" there may be no reason for me to update or delete the subState. Was there a particular reason for this processing requirement?
    Similar sub attributes.



    2.3.1.34 subType

    2.3.1.35 subState

    D.1.2.2 subFs



    .do not have this requirement.



    Thanks,

    Ryan








  • 3.  RE: [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype processing requirements

    Posted 05-29-2013 17:19
    All of the sub properties already have the a similar PR to the following:


    * If the attribute subtype is used, the attribute type must be specified as well.

    So if your statement "I think this PR comes from the constraint that you should not have a subtype without a type, therefore the subtype is linked to the type (it complements it)." applies to subType in <mtc:matches> shouldn't it also apply to all sub attributes: 2.3.1.34 subType, 2.3.1.35 subState, D.1.2.2 subFs? I think it should be all or nothing to avoid confusion, or maybe just the PR noted above is enough to show the relationship?

    Ryan



    From: Yves Savourel [mailto:yves@opentag.com]
    Sent: Wednesday, May 29, 2013 3:47 AM
    To: xliff-comment@lists.oasis-open.org
    Subject: RE: [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype processing requirements

    I think this PR comes from the constraint that you should not have a subtype without a type, therefore the subtype is linked to the type (it complements it).
    In your example, if a type can have the same subtype value you can have an "invisible" update: the updated subtype value simply happens to have the same value as before.

    -ys

    From: Ryan King [mailto:ryanki@microsoft.com]
    Sent: Wednesday, May 29, 2013 2:05 AM
    To: xliff-comment@lists.oasis-open.org<mailto:xliff-comment@lists.oasis-open.org>
    Cc: xliff@lists.oasis-open.org<mailto:xliff@lists.oasis-open.org>
    Subject: [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype processing requirements

    B.1.3.7 subtype processing requirements state:

    If the attribute type is modified, the attribute subtype must be updated or deleted.

    Is this always the case? What if I have a two types, e.g. "tm" and "mt", that have the same subType? If my type changes from "tm" to "mt" there may be no reason for me to update or delete the subState. Was there a particular reason for this processing requirement? Similar sub attributes...

    2.3.1.34 subType
    2.3.1.35 subState
    D.1.2.2 subFs

    ...do not have this requirement.

    Thanks,
    Ryan





  • 4.  RE: [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype processing requirements

    Posted 05-29-2013 18:15
    I tend to agree.





    From: Ryan King [mailto:ryanki@microsoft.com]
    Sent: Wednesday, May 29, 2013 11:19 AM
    To: Yves Savourel; xliff-comment@lists.oasis-open.org
    Subject: RE: [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype processing requirements



    All of the sub properties already have the a similar PR to the following:



    . If the attribute subtype is used, the attribute type must be specified as well.



    So if your statement "I think this PR comes from the constraint that you should not have a subtype without a type, therefore the
    subtype is linked to the type (it complements it)." applies to subType in <mtc:matches> shouldn't it also apply to all sub
    attributes: 2.3.1.34 subType, 2.3.1.35 subState, D.1.2.2 subFs? I think it should be all or nothing to avoid confusion, or maybe
    just the PR noted above is enough to show the relationship?



    Ryan







    From: Yves Savourel [mailto:yves@opentag.com]
    Sent: Wednesday, May 29, 2013 3:47 AM
    To: xliff-comment@lists.oasis-open.org
    Subject: RE: [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype processing requirements



    I think this PR comes from the constraint that you should not have a subtype without a type, therefore the subtype is linked to the
    type (it complements it).

    In your example, if a type can have the same subtype value you can have an "invisible" update: the updated subtype value simply
    happens to have the same value as before.



    -ys



    From: Ryan King [mailto:ryanki@microsoft.com]
    Sent: Wednesday, May 29, 2013 2:05 AM
    To: xliff-comment@lists.oasis-open.org
    Cc: xliff@lists.oasis-open.org
    Subject: [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype processing requirements



    B.1.3.7 subtype processing requirements state:



    If the attribute type is modified, the attribute subtype must be updated or deleted.



    Is this always the case? What if I have a two types, e.g. "tm" and "mt", that have the same subType? If my type changes from "tm" to
    "mt" there may be no reason for me to update or delete the subState. Was there a particular reason for this processing requirement?
    Similar sub attributes.



    2.3.1.34 subType

    2.3.1.35 subState

    D.1.2.2 subFs



    .do not have this requirement.



    Thanks,

    Ryan








  • 5.  Re: [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype processing requirements

    Posted 05-30-2013 12:02
    I think the update/drop of sub* should be enforced throughout the sub*
    attributes..

    If you own the subtype, it is easy to know the invisible update, I would
    not be worried with that.
    The PR is important to those who do not know the predefined subproperties.
    If you cannot update, you MUST drop.. *Something* MUST be done to
    subproperty if property changed..


    David Filip, Ph.D.
    =====================
    *cellphone: +353-86-0222-158*
    mailto:davidf@davidf.org
    www.davidf.org, http://www.linkedin.com/in/davidfatdavidf


    On Wed, May 29, 2013 at 7:15 PM, Yves Savourel <yves@opentag.com> wrote:

    > I tend to agree.****
    >
    > ** **
    >
    > ** **
    >
    > *From:* Ryan King [mailto:ryanki@microsoft.com]
    > *Sent:* Wednesday, May 29, 2013 11:19 AM
    > *To:* Yves Savourel; xliff-comment@lists.oasis-open.org
    >
    > *Subject:* RE: [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype
    > processing requirements****
    >
    > ** **
    >
    > All of the sub properties already have the a similar PR to the following:*
    > ***
    >
    > ** **
    >
    > · If the attribute subtype is used, the attribute type must be
    > specified as well.****
    >
    > ** **
    >
    > So if your statement “I think this PR comes from the constraint that you
    > should not have a subtype without a type, therefore the subtype is linked
    > to the type (it complements it).” applies to subType in <mtc:matches>
    > shouldn’t it also apply to all sub attributes: 2.3.1.34 subType, 2.3.1.35
    > subState, D.1.2.2 subFs? I think it should be all or nothing to avoid
    > confusion, or maybe just the PR noted above is enough to show the
    > relationship?****
    >
    > ** **
    >
    > Ryan****
    >
    > ** **
    >
    > ** **
    >
    > ** **
    >
    > *From:* Yves Savourel [mailto:yves@opentag.com <yves@opentag.com>]
    > *Sent:* Wednesday, May 29, 2013 3:47 AM
    > *To:* xliff-comment@lists.oasis-open.org
    > *Subject:* RE: [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype
    > processing requirements****
    >
    > ** **
    >
    > I think this PR comes from the constraint that you should not have a
    > subtype without a type, therefore the subtype is linked to the type (it
    > complements it).****
    >
    > In your example, if a type can have the same subtype value you can have an
    > “invisible” update: the updated subtype value simply happens to have the
    > same value as before.****
    >
    > ** **
    >
    > -ys****
    >
    > ** **
    >
    > *From:* Ryan King [mailto:ryanki@microsoft.com <ryanki@microsoft.com>]
    > *Sent:* Wednesday, May 29, 2013 2:05 AM
    > *To:* xliff-comment@lists.oasis-open.org
    > *Cc:* xliff@lists.oasis-open.org
    > *Subject:* [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype
    > processing requirements****
    >
    > ** **
    >
    > B.1.3.7 subtype processing requirements state:****
    >
    > ** **
    >
    > If the attribute type is modified, the attribute subtype must be updated
    > or deleted.****
    >
    > ** **
    >
    > Is this always the case? What if I have a two types, e.g. “tm” and “mt”,
    > that have the same subType? If my type changes from “tm” to “mt” there may
    > be no reason for me to update or delete the subState. Was there a
    > particular reason for this processing requirement? Similar sub attributes…
    > ****
    >
    > ** **
    >
    > 2.3.1.34 subType****
    >
    > 2.3.1.35 subState****
    >
    > D.1.2.2 subFs****
    >
    > ** **
    >
    > …do not have this requirement.****
    >
    > ** **
    >
    > Thanks,****
    >
    > Ryan****
    >
    > ** **
    >
    > ** **
    >



  • 6.  RE: [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype processing requirements

    Posted 05-30-2013 17:15
    >> If you cannot update, you MUST drop.. *Something* MUST be done to subproperty if property changed..

    I'm not totally convinced that it MUST be dropped. As an example:

    First handoff:

    <segment state="initial">
    hello
    </segment>

    <segment state="translated">
    hello
    <target>halló</target>
    </segment>

    Second handoff:

    <segment state="translated" subState="xy:sourceUpdate">
    hello world
    <target>halló</target>
    </segment>

    <segment state="translated" subState="xy:sourceUpdate">
    hello world
    <target>halló veröld</target>
    </segment>

    <segment state="reviewed" subState="xy:sourceUpdate">
    hello world
    <target>halló veröld</target>
    </segment>


    If I understand ms:sourceUpdate, I could clear subState after setting the state to "reviewed", however, if I don't understand ms:sourceUpdate, couldn't I treat it like any other extension (it is after all a type of extensibility) and just ignore it but preserve it? It could very well be that the content provider that owns xy:sourceUpdate wants to know that a particular handed-back <segment>, which was updated, was indeed re-translated and reviewed. The advantage to a xlf:subState over some arbitrary extension such as xy:subState is that editors, for example, could relate it and display it with xlf:state in a consistent manner because Processing Instructions state: If the attribute subtype is used, the attribute type must be specified as well.


    From: David Filip [mailto:davidf@davidf.org]
    Sent: Thursday, May 30, 2013 5:02 AM
    To: Yves Savourel; Ryan King
    Cc: xliff-comment@lists.oasis-open.org
    Subject: Re: [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype processing requirements

    I think the update/drop of sub* should be enforced throughout the sub* attributes..

    If you own the subtype, it is easy to know the invisible update, I would not be worried with that.
    The PR is important to those who do not know the predefined subproperties.
    If you cannot update, you MUST drop.. *Something* MUST be done to subproperty if property changed..


    David Filip, Ph.D.
    =====================
    cellphone: +353-86-0222-158
    mailto:davidf@davidf.org<mailto:davidf@davidf.org>
    www.davidf.org<http://www.davidf.org>, http://www.linkedin.com/in/davidfatdavidf

    On Wed, May 29, 2013 at 7:15 PM, Yves Savourel <yves@opentag.com<mailto:yves@opentag.com>> wrote:
    I tend to agree.


    From: Ryan King [mailto:ryanki@microsoft.com<mailto:ryanki@microsoft.com>]
    Sent: Wednesday, May 29, 2013 11:19 AM
    To: Yves Savourel; xliff-comment@lists.oasis-open.org<mailto:xliff-comment@lists.oasis-open.org>

    Subject: RE: [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype processing requirements

    All of the sub properties already have the a similar PR to the following:


    * If the attribute subtype is used, the attribute type must be specified as well.

    So if your statement "I think this PR comes from the constraint that you should not have a subtype without a type, therefore the subtype is linked to the type (it complements it)." applies to subType in <mtc:matches> shouldn't it also apply to all sub attributes: 2.3.1.34 subType, 2.3.1.35 subState, D.1.2.2 subFs? I think it should be all or nothing to avoid confusion, or maybe just the PR noted above is enough to show the relationship?

    Ryan



    From: Yves Savourel [mailto:yves@opentag.com]
    Sent: Wednesday, May 29, 2013 3:47 AM
    To: xliff-comment@lists.oasis-open.org<mailto:xliff-comment@lists.oasis-open.org>
    Subject: RE: [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype processing requirements

    I think this PR comes from the constraint that you should not have a subtype without a type, therefore the subtype is linked to the type (it complements it).
    In your example, if a type can have the same subtype value you can have an "invisible" update: the updated subtype value simply happens to have the same value as before.

    -ys

    From: Ryan King [mailto:ryanki@microsoft.com]
    Sent: Wednesday, May 29, 2013 2:05 AM
    To: xliff-comment@lists.oasis-open.org<mailto:xliff-comment@lists.oasis-open.org>
    Cc: xliff@lists.oasis-open.org<mailto:xliff@lists.oasis-open.org>
    Subject: [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype processing requirements

    B.1.3.7 subtype processing requirements state:

    If the attribute type is modified, the attribute subtype must be updated or deleted.

    Is this always the case? What if I have a two types, e.g. "tm" and "mt", that have the same subType? If my type changes from "tm" to "mt" there may be no reason for me to update or delete the subState. Was there a particular reason for this processing requirement? Similar sub attributes...

    2.3.1.34 subType
    2.3.1.35 subState
    D.1.2.2 subFs

    ...do not have this requirement.

    Thanks,
    Ryan






  • 7.  RE: [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype processing requirements

    Posted 05-30-2013 17:57
    Sorry for the cut and paste typo below:
    ms:sourceUpdate and xy:sourceUpdate are intended to be the same property, I just want to make sure I don't introduce confusion.

    From: Ryan King [mailto:ryanki@microsoft.com]
    Sent: Thursday, May 30, 2013 10:15 AM
    To: David Filip; Yves Savourel
    Cc: xliff-comment@lists.oasis-open.org
    Subject: RE: [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype processing requirements

    >> If you cannot update, you MUST drop.. *Something* MUST be done to subproperty if property changed..

    I'm not totally convinced that it MUST be dropped. As an example:

    First handoff:

    <segment state="initial">
    hello
    </segment>

    <segment state="translated">
    hello
    <target>halló</target>
    </segment>

    Second handoff:

    <segment state="translated" subState="xy:sourceUpdate">
    hello world
    <target>halló</target>
    </segment>

    <segment state="translated" subState="xy:sourceUpdate">
    hello world
    <target>halló veröld</target>
    </segment>

    <segment state="reviewed" subState="xy:sourceUpdate">
    hello world
    <target>halló veröld</target>
    </segment>


    If I understand ms:sourceUpdate, I could clear subState after setting the state to "reviewed", however, if I don't understand ms:sourceUpdate, couldn't I treat it like any other extension (it is after all a type of extensibility) and just ignore it but preserve it? It could very well be that the content provider that owns xy:sourceUpdate wants to know that a particular handed-back <segment>, which was updated, was indeed re-translated and reviewed. The advantage to a xlf:subState over some arbitrary extension such as xy:subState is that editors, for example, could relate it and display it with xlf:state in a consistent manner because Processing Instructions state: If the attribute subtype is used, the attribute type must be specified as well.


    From: David Filip [mailto:davidf@davidf.org]
    Sent: Thursday, May 30, 2013 5:02 AM
    To: Yves Savourel; Ryan King
    Cc: xliff-comment@lists.oasis-open.org<mailto:xliff-comment@lists.oasis-open.org>
    Subject: Re: [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype processing requirements

    I think the update/drop of sub* should be enforced throughout the sub* attributes..

    If you own the subtype, it is easy to know the invisible update, I would not be worried with that.
    The PR is important to those who do not know the predefined subproperties.
    If you cannot update, you MUST drop.. *Something* MUST be done to subproperty if property changed..


    David Filip, Ph.D.
    =====================
    cellphone: +353-86-0222-158
    mailto:davidf@davidf.org<mailto:davidf@davidf.org>
    www.davidf.org<http://www.davidf.org>, http://www.linkedin.com/in/davidfatdavidf

    On Wed, May 29, 2013 at 7:15 PM, Yves Savourel <yves@opentag.com<mailto:yves@opentag.com>> wrote:
    I tend to agree.


    From: Ryan King [mailto:ryanki@microsoft.com<mailto:ryanki@microsoft.com>]
    Sent: Wednesday, May 29, 2013 11:19 AM
    To: Yves Savourel; xliff-comment@lists.oasis-open.org<mailto:xliff-comment@lists.oasis-open.org>

    Subject: RE: [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype processing requirements

    All of the sub properties already have the a similar PR to the following:


    * If the attribute subtype is used, the attribute type must be specified as well.

    So if your statement "I think this PR comes from the constraint that you should not have a subtype without a type, therefore the subtype is linked to the type (it complements it)." applies to subType in <mtc:matches> shouldn't it also apply to all sub attributes: 2.3.1.34 subType, 2.3.1.35 subState, D.1.2.2 subFs? I think it should be all or nothing to avoid confusion, or maybe just the PR noted above is enough to show the relationship?

    Ryan



    From: Yves Savourel [mailto:yves@opentag.com]
    Sent: Wednesday, May 29, 2013 3:47 AM
    To: xliff-comment@lists.oasis-open.org<mailto:xliff-comment@lists.oasis-open.org>
    Subject: RE: [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype processing requirements

    I think this PR comes from the constraint that you should not have a subtype without a type, therefore the subtype is linked to the type (it complements it).
    In your example, if a type can have the same subtype value you can have an "invisible" update: the updated subtype value simply happens to have the same value as before.

    -ys

    From: Ryan King [mailto:ryanki@microsoft.com]
    Sent: Wednesday, May 29, 2013 2:05 AM
    To: xliff-comment@lists.oasis-open.org<mailto:xliff-comment@lists.oasis-open.org>
    Cc: xliff@lists.oasis-open.org<mailto:xliff@lists.oasis-open.org>
    Subject: [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype processing requirements

    B.1.3.7 subtype processing requirements state:

    If the attribute type is modified, the attribute subtype must be updated or deleted.

    Is this always the case? What if I have a two types, e.g. "tm" and "mt", that have the same subType? If my type changes from "tm" to "mt" there may be no reason for me to update or delete the subState. Was there a particular reason for this processing requirement? Similar sub attributes...

    2.3.1.34 subType
    2.3.1.35 subState
    D.1.2.2 subFs

    ...do not have this requirement.

    Thanks,
    Ryan






  • 8.  RE: [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype processing requirements

    Posted 05-30-2013 18:21
    Ryan,

    An unrelated comment to this thread (but I think that yet important to point out) is that for the second handoff, the logical state of the changed segment should be reverted back to "initial", regardless of if <target> is primed with something potentially useful (or not) for the translator.

    Otherwise it will not be possible for a tool to tell if it makes sense to consider the segment as really translated or not. Please note that there are no differences in attributes for the first two stages of the second handoff, and tools cannot (yet) understand natural language well enough to infer the state of the segment in the same way a human being could do it.

    <segment state="initial" subState="xy:sourceUpdate">
    hello world
    <target>halló</target>
    </segment>

    Regards,
    Josep.


    ________________________________
    De: Ryan King [mailto:ryanki@microsoft.com]
    Enviado el: jueves, 30 de mayo de 2013 19:15
    Para: David Filip; Yves Savourel
    CC: xliff-comment@lists.oasis-open.org
    Asunto: RE: [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype processing requirements

    >> If you cannot update, you MUST drop.. *Something* MUST be done to subproperty if property changed..

    I'm not totally convinced that it MUST be dropped. As an example:

    First handoff:

    <segment state="initial">
    hello
    </segment>

    <segment state="translated">
    hello
    <target>halló</target>
    </segment>

    Second handoff:

    <segment state="translated" subState="xy:sourceUpdate">
    hello world
    <target>halló</target>
    </segment>

    <segment state="translated" subState="xy:sourceUpdate">
    hello world
    <target>halló veröld</target>
    </segment>

    <segment state="reviewed" subState="xy:sourceUpdate">
    hello world
    <target>halló veröld</target>
    </segment>


    If I understand ms:sourceUpdate, I could clear subState after setting the state to "reviewed", however, if I don't understand ms:sourceUpdate, couldn't I treat it like any other extension (it is after all a type of extensibility) and just ignore it but preserve it? It could very well be that the content provider that owns xy:sourceUpdate wants to know that a particular handed-back <segment>, which was updated, was indeed re-translated and reviewed. The advantage to a xlf:subState over some arbitrary extension such as xy:subState is that editors, for example, could relate it and display it with xlf:state in a consistent manner because Processing Instructions state: If the attribute subtype is used, the attribute type must be specified as well.


    From: David Filip [mailto:davidf@davidf.org]
    Sent: Thursday, May 30, 2013 5:02 AM
    To: Yves Savourel; Ryan King
    Cc: xliff-comment@lists.oasis-open.org
    Subject: Re: [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype processing requirements

    I think the update/drop of sub* should be enforced throughout the sub* attributes..

    If you own the subtype, it is easy to know the invisible update, I would not be worried with that.
    The PR is important to those who do not know the predefined subproperties.
    If you cannot update, you MUST drop.. *Something* MUST be done to subproperty if property changed..


    David Filip, Ph.D.
    =====================
    cellphone: +353-86-0222-158
    mailto:davidf@davidf.org<mailto:davidf@davidf.org>
    www.davidf.org<http://www.davidf.org>, http://www.linkedin.com/in/davidfatdavidf

    On Wed, May 29, 2013 at 7:15 PM, Yves Savourel <yves@opentag.com<mailto:yves@opentag.com>> wrote:
    I tend to agree.


    From: Ryan King [mailto:ryanki@microsoft.com<mailto:ryanki@microsoft.com>]
    Sent: Wednesday, May 29, 2013 11:19 AM
    To: Yves Savourel; xliff-comment@lists.oasis-open.org<mailto:xliff-comment@lists.oasis-open.org>

    Subject: RE: [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype processing requirements

    All of the sub properties already have the a similar PR to the following:


    * If the attribute subtype is used, the attribute type must be specified as well.

    So if your statement "I think this PR comes from the constraint that you should not have a subtype without a type, therefore the subtype is linked to the type (it complements it)." applies to subType in <mtc:matches> shouldn't it also apply to all sub attributes: 2.3.1.34 subType, 2.3.1.35 subState, D.1.2.2 subFs? I think it should be all or nothing to avoid confusion, or maybe just the PR noted above is enough to show the relationship?

    Ryan



    From: Yves Savourel [mailto:yves@opentag.com]
    Sent: Wednesday, May 29, 2013 3:47 AM
    To: xliff-comment@lists.oasis-open.org<mailto:xliff-comment@lists.oasis-open.org>
    Subject: RE: [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype processing requirements

    I think this PR comes from the constraint that you should not have a subtype without a type, therefore the subtype is linked to the type (it complements it).
    In your example, if a type can have the same subtype value you can have an "invisible" update: the updated subtype value simply happens to have the same value as before.

    -ys

    From: Ryan King [mailto:ryanki@microsoft.com]
    Sent: Wednesday, May 29, 2013 2:05 AM
    To: xliff-comment@lists.oasis-open.org<mailto:xliff-comment@lists.oasis-open.org>
    Cc: xliff@lists.oasis-open.org<mailto:xliff@lists.oasis-open.org>
    Subject: [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype processing requirements

    B.1.3.7 subtype processing requirements state:

    If the attribute type is modified, the attribute subtype must be updated or deleted.

    Is this always the case? What if I have a two types, e.g. "tm" and "mt", that have the same subType? If my type changes from "tm" to "mt" there may be no reason for me to update or delete the subState. Was there a particular reason for this processing requirement? Similar sub attributes...

    2.3.1.34 subType
    2.3.1.35 subState
    D.1.2.2 subFs

    ...do not have this requirement.

    Thanks,
    Ryan






  • 9.  RE: [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype processing requirements

    Posted 05-30-2013 18:33
    Thank you Josep for pointing this out. I agree with your logic on this point. In my original example, tools aware of xy:sourceUpdate could alert a translator to review and possibly re-translate the segment whether the state is translated or initial. However, tools not aware of xy:sourceUpdate would need to rely on state alone, and therefore, your example makes more sense here.

    From: Josep Condal [mailto:pcondal@apsic.com]
    Sent: Thursday, May 30, 2013 11:21 AM
    To: Ryan King; David Filip; Yves Savourel
    Cc: xliff-comment@lists.oasis-open.org
    Subject: RE: [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype processing requirements

    Ryan,

    An unrelated comment to this thread (but I think that yet important to point out) is that for the second handoff, the logical state of the changed segment should be reverted back to "initial", regardless of if <target> is primed with something potentially useful (or not) for the translator.

    Otherwise it will not be possible for a tool to tell if it makes sense to consider the segment as really translated or not. Please note that there are no differences in attributes for the first two stages of the second handoff, and tools cannot (yet) understand natural language well enough to infer the state of the segment in the same way a human being could do it.

    <segment state="initial" subState="xy:sourceUpdate">
    hello world
    <target>halló</target>
    </segment>

    Regards,
    Josep.


    ________________________________
    De: Ryan King [mailto:ryanki@microsoft.com]
    Enviado el: jueves, 30 de mayo de 2013 19:15
    Para: David Filip; Yves Savourel
    CC: xliff-comment@lists.oasis-open.org<mailto:xliff-comment@lists.oasis-open.org>
    Asunto: RE: [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype processing requirements
    >> If you cannot update, you MUST drop.. *Something* MUST be done to subproperty if property changed..

    I'm not totally convinced that it MUST be dropped. As an example:

    First handoff:

    <segment state="initial">
    hello
    </segment>

    <segment state="translated">
    hello
    <target>halló</target>
    </segment>

    Second handoff:

    <segment state="translated" subState="xy:sourceUpdate">
    hello world
    <target>halló</target>
    </segment>

    <segment state="translated" subState="xy:sourceUpdate">
    hello world
    <target>halló veröld</target>
    </segment>

    <segment state="reviewed" subState="xy:sourceUpdate">
    hello world
    <target>halló veröld</target>
    </segment>


    If I understand ms:sourceUpdate, I could clear subState after setting the state to "reviewed", however, if I don't understand ms:sourceUpdate, couldn't I treat it like any other extension (it is after all a type of extensibility) and just ignore it but preserve it? It could very well be that the content provider that owns xy:sourceUpdate wants to know that a particular handed-back <segment>, which was updated, was indeed re-translated and reviewed. The advantage to a xlf:subState over some arbitrary extension such as xy:subState is that editors, for example, could relate it and display it with xlf:state in a consistent manner because Processing Instructions state: If the attribute subtype is used, the attribute type must be specified as well.


    From: David Filip [mailto:davidf@davidf.org]
    Sent: Thursday, May 30, 2013 5:02 AM
    To: Yves Savourel; Ryan King
    Cc: xliff-comment@lists.oasis-open.org<mailto:xliff-comment@lists.oasis-open.org>
    Subject: Re: [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype processing requirements

    I think the update/drop of sub* should be enforced throughout the sub* attributes..

    If you own the subtype, it is easy to know the invisible update, I would not be worried with that.
    The PR is important to those who do not know the predefined subproperties.
    If you cannot update, you MUST drop.. *Something* MUST be done to subproperty if property changed..


    David Filip, Ph.D.
    =====================
    cellphone: +353-86-0222-158
    mailto:davidf@davidf.org<mailto:davidf@davidf.org>
    www.davidf.org<http://www.davidf.org>, http://www.linkedin.com/in/davidfatdavidf

    On Wed, May 29, 2013 at 7:15 PM, Yves Savourel <yves@opentag.com<mailto:yves@opentag.com>> wrote:
    I tend to agree.


    From: Ryan King [mailto:ryanki@microsoft.com<mailto:ryanki@microsoft.com>]
    Sent: Wednesday, May 29, 2013 11:19 AM
    To: Yves Savourel; xliff-comment@lists.oasis-open.org<mailto:xliff-comment@lists.oasis-open.org>

    Subject: RE: [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype processing requirements

    All of the sub properties already have the a similar PR to the following:


    * If the attribute subtype is used, the attribute type must be specified as well.

    So if your statement "I think this PR comes from the constraint that you should not have a subtype without a type, therefore the subtype is linked to the type (it complements it)." applies to subType in <mtc:matches> shouldn't it also apply to all sub attributes: 2.3.1.34 subType, 2.3.1.35 subState, D.1.2.2 subFs? I think it should be all or nothing to avoid confusion, or maybe just the PR noted above is enough to show the relationship?

    Ryan



    From: Yves Savourel [mailto:yves@opentag.com]
    Sent: Wednesday, May 29, 2013 3:47 AM
    To: xliff-comment@lists.oasis-open.org<mailto:xliff-comment@lists.oasis-open.org>
    Subject: RE: [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype processing requirements

    I think this PR comes from the constraint that you should not have a subtype without a type, therefore the subtype is linked to the type (it complements it).
    In your example, if a type can have the same subtype value you can have an "invisible" update: the updated subtype value simply happens to have the same value as before.

    -ys

    From: Ryan King [mailto:ryanki@microsoft.com]
    Sent: Wednesday, May 29, 2013 2:05 AM
    To: xliff-comment@lists.oasis-open.org<mailto:xliff-comment@lists.oasis-open.org>
    Cc: xliff@lists.oasis-open.org<mailto:xliff@lists.oasis-open.org>
    Subject: [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype processing requirements

    B.1.3.7 subtype processing requirements state:

    If the attribute type is modified, the attribute subtype must be updated or deleted.

    Is this always the case? What if I have a two types, e.g. "tm" and "mt", that have the same subType? If my type changes from "tm" to "mt" there may be no reason for me to update or delete the subState. Was there a particular reason for this processing requirement? Similar sub attributes...

    2.3.1.34 subType
    2.3.1.35 subState
    D.1.2.2 subFs

    ...do not have this requirement.

    Thanks,
    Ryan






  • 10.  Re: [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype processing requirements

    Posted 05-31-2013 16:46
    Guys, Chet, pointed out in another conversation that the comment list is
    not intended for discussions.
    This discussion either has to happen between Ryan and Josep and Ryan can
    update the TC on the result.
    Or, Josep, we cordially invite you to join the TC :-) and continue the
    discussion on the TC list

    Rgds
    dF

    David Filip, Ph.D.
    =====================
    *cellphone: +353-86-0222-158*
    mailto:davidf@davidf.org
    www.davidf.org, http://www.linkedin.com/in/davidfatdavidf


    On Thu, May 30, 2013 at 7:32 PM, Ryan King <ryanki@microsoft.com> wrote:

    > Thank you Josep for pointing this out. I agree with your logic on this
    > point. In my original example, tools aware of xy:sourceUpdate could alert a
    > translator to review and possibly re-translate the segment whether the
    > state is translated or initial. However, tools not aware of xy:sourceUpdate
    > would need to rely on state alone, and therefore, your example makes more
    > sense here.****
    >
    > ** **
    >
    > *From:* Josep Condal [mailto:pcondal@apsic.com]
    > *Sent:* Thursday, May 30, 2013 11:21 AM
    > *To:* Ryan King; David Filip; Yves Savourel
    > *Cc:* xliff-comment@lists.oasis-open.org
    >
    > *Subject:* RE: [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype
    > processing requirements****
    >
    > ** **
    >
    > Ryan,****
    >
    > ****
    >
    > An unrelated comment to this thread (but I think that yet important to
    > point out) is that for the second handoff, the logical state of the changed
    > segment should be reverted back to "initial", regardless of if <target> is
    > primed with something potentially useful (or not) for the translator. ***
    > *
    >
    > ****
    >
    > Otherwise it will not be possible for a tool to tell if it makes sense to
    > consider the segment as really translated or not. Please note that there
    > are no differences in attributes for the first two stages of the second
    > handoff, and tools cannot (yet) understand natural language well enough
    > to infer the state of the segment in the same way a human being could do it.
    > ****
    >
    > ****
    >
    > <segment state=”*initial*” subState=”xy:sourceUpdate”>****
    >
    > hello world****
    >
    > <target>halló</target>****
    >
    > </segment>****
    >
    > ****
    >
    > Regards,****
    >
    > Josep.****
    >
    > ****
    >
    > ** **
    > ------------------------------
    >
    > *De:* Ryan King [mailto:ryanki@microsoft.com <ryanki@microsoft.com>]
    > *Enviado el:* jueves, 30 de mayo de 2013 19:15
    > *Para:* David Filip; Yves Savourel
    > *CC:* xliff-comment@lists.oasis-open.org
    > *Asunto:* RE: [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype
    > processing requirements****
    >
    > >> If you cannot update, you MUST drop.. *Something* MUST be done to
    > subproperty if property changed..****
    >
    > ** **
    >
    > I’m not totally convinced that it MUST be dropped. As an example:****
    >
    > ** **
    >
    > First handoff:****
    >
    > ** **
    >
    > <segment state=”initial”>****
    >
    > hello****
    >
    > </segment>****
    >
    > ** **
    >
    > <segment state=”translated”>****
    >
    > hello****
    >
    > <target>halló</target>****
    >
    > </segment>****
    >
    > ** **
    >
    > Second handoff:****
    >
    > ** **
    >
    > <segment state=”translated” subState=”xy:sourceUpdate”>****
    >
    > hello world****
    >
    > <target>halló</target>****
    >
    > </segment>****
    >
    > ** **
    >
    > <segment state=”translated” subState=”xy:sourceUpdate”>****
    >
    > hello world****
    >
    > <target>halló veröld</target>****
    >
    > </segment>****
    >
    > ** **
    >
    > <segment state=”reviewed” subState=”xy:sourceUpdate”>****
    >
    > hello world****
    >
    > <target>halló veröld</target>****
    >
    > </segment>****
    >
    > ** **
    >
    > ** **
    >
    > If I understand ms:sourceUpdate, I could clear subState after setting the
    > state to “reviewed”, however, if I don’t understand ms:sourceUpdate,
    > couldn’t I treat it like any other extension (it is after all a type of
    > extensibility) and just ignore it but preserve it? It could very well be
    > that the content provider that owns xy:sourceUpdate wants to know that a
    > particular handed-back <segment>, which was updated, was indeed
    > re-translated and reviewed. The advantage to a xlf:subState over some
    > arbitrary extension such as xy:subState is that editors, for example, could
    > relate it and display it with xlf:state in a consistent manner because
    > Processing Instructions state: If the attribute subtype is used, the
    > attribute type must be specified as well.****
    >
    > ** **
    >
    > ** **
    >
    > *From:* David Filip [mailto:davidf@davidf.org <davidf@davidf.org>]
    > *Sent:* Thursday, May 30, 2013 5:02 AM
    > *To:* Yves Savourel; Ryan King
    > *Cc:* xliff-comment@lists.oasis-open.org
    > *Subject:* Re: [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype
    > processing requirements****
    >
    > ** **
    >
    > I think the update/drop of sub* should be enforced throughout the sub*
    > attributes..****
    >
    > ** **
    >
    > If you own the subtype, it is easy to know the invisible update, I would
    > not be worried with that.****
    >
    > The PR is important to those who do not know the predefined subproperties.
    > ****
    >
    > If you cannot update, you MUST drop.. *Something* MUST be done to
    > subproperty if property changed..****
    >
    > ** **
    >
    > ** **
    >
    > David Filip, Ph.D.
    > =====================
    > *cellphone: +353-86-0222-158*
    > mailto:davidf@davidf.org****
    >
    > www.davidf.org, http://www.linkedin.com/in/davidfatdavidf****
    >
    > ** **
    >
    > On Wed, May 29, 2013 at 7:15 PM, Yves Savourel <yves@opentag.com> wrote:**
    > **
    >
    > I tend to agree.****
    >
    > ****
    >
    > ****
    >
    > *From:* Ryan King [mailto:ryanki@microsoft.com]
    > *Sent:* Wednesday, May 29, 2013 11:19 AM
    > *To:* Yves Savourel; xliff-comment@lists.oasis-open.org****
    >
    >
    > *Subject:* RE: [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype
    > processing requirements****
    >
    > ****
    >
    > All of the sub properties already have the a similar PR to the following:*
    > ***
    >
    > ****
    >
    > · If the attribute subtype is used, the attribute type must be
    > specified as well.****
    >
    > ****
    >
    > So if your statement “I think this PR comes from the constraint that you
    > should not have a subtype without a type, therefore the subtype is linked
    > to the type (it complements it).” applies to subType in <mtc:matches>
    > shouldn’t it also apply to all sub attributes: 2.3.1.34 subType, 2.3.1.35
    > subState, D.1.2.2 subFs? I think it should be all or nothing to avoid
    > confusion, or maybe just the PR noted above is enough to show the
    > relationship?****
    >
    > ****
    >
    > Ryan****
    >
    > ****
    >
    > ****
    >
    > ****
    >
    > *From:* Yves Savourel [mailto:yves@opentag.com <yves@opentag.com>]
    > *Sent:* Wednesday, May 29, 2013 3:47 AM
    > *To:* xliff-comment@lists.oasis-open.org
    > *Subject:* RE: [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype
    > processing requirements****
    >
    > ****
    >
    > I think this PR comes from the constraint that you should not have a
    > subtype without a type, therefore the subtype is linked to the type (it
    > complements it).****
    >
    > In your example, if a type can have the same subtype value you can have an
    > “invisible” update: the updated subtype value simply happens to have the
    > same value as before.****
    >
    > ****
    >
    > -ys****
    >
    > ****
    >
    > *From:* Ryan King [mailto:ryanki@microsoft.com <ryanki@microsoft.com>]
    > *Sent:* Wednesday, May 29, 2013 2:05 AM
    > *To:* xliff-comment@lists.oasis-open.org
    > *Cc:* xliff@lists.oasis-open.org
    > *Subject:* [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype
    > processing requirements****
    >
    > ****
    >
    > B.1.3.7 subtype processing requirements state:****
    >
    > ****
    >
    > If the attribute type is modified, the attribute subtype must be updated
    > or deleted.****
    >
    > ****
    >
    > Is this always the case? What if I have a two types, e.g. “tm” and “mt”,
    > that have the same subType? If my type changes from “tm” to “mt” there may
    > be no reason for me to update or delete the subState. Was there a
    > particular reason for this processing requirement? Similar sub attributes…
    > ****
    >
    > ****
    >
    > 2.3.1.34 subType****
    >
    > 2.3.1.35 subState****
    >
    > D.1.2.2 subFs****
    >
    > ****
    >
    > …do not have this requirement.****
    >
    > ****
    >
    > Thanks,****
    >
    > Ryan****
    >
    > ****
    >
    > ****
    >
    > ** **
    >



  • 11.  Re: [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype processing requirements

    Posted 05-31-2013 16:47
    Guys, Chet, pointed out in another conversation that the comment list is not intended for discussions. This discussion either has to happen between Ryan and Josep and Ryan can update the TC on the result. Or, Josep, we cordially invite you to join the TC :-) and continue the discussion on the TC list Rgds dF David Filip, Ph.D. ===================== cellphone: +353-86-0222-158 mailto: davidf@davidf.org www.davidf.org , http://www.linkedin.com/in/davidfatdavidf On Thu, May 30, 2013 at 7:32 PM, Ryan King < ryanki@microsoft.com > wrote: Thank you Josep for pointing this out. I agree with your logic on this point. In my original example, tools aware of xy:sourceUpdate could alert a translator to review and possibly re-translate the segment whether the state is translated or initial. However, tools not aware of xy:sourceUpdate would need to rely on state alone, and therefore, your example makes more sense here.   From: Josep Condal [mailto: pcondal@apsic.com ] Sent: Thursday, May 30, 2013 11:21 AM To: Ryan King; David Filip; Yves Savourel Cc: xliff-comment@lists.oasis-open.org Subject: RE: [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype processing requirements   Ryan,   An unrelated comment to this thread (but I think that yet important to point out) is that for the second handoff, the logical state of the changed segment should be reverted back to "initial", regardless of if <target> is primed with something potentially useful (or not) for the translator.    Otherwise it will not be possible for a tool to tell if it makes sense to consider the segment as really translated or not. Please note that there are no differences in attributes for the first two stages of the second handoff, and tools cannot (yet) understand natural language well enough to infer the state of the segment in the same way a human being could do it.   <segment state=” initial ” subState=”xy:sourceUpdate”>                <source>hello world</source>                <target>halló</target> </segment>   Regards, Josep.     De: Ryan King [ mailto:ryanki@microsoft.com ] Enviado el: jueves, 30 de mayo de 2013 19:15 Para: David Filip; Yves Savourel CC: xliff-comment@lists.oasis-open.org Asunto: RE: [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype processing requirements >> If you cannot update, you MUST drop.. *Something* MUST be done to subproperty if property changed..   I’m not totally convinced that it MUST be dropped. As an example:   First handoff:   <segment state=”initial”>                <source>hello</source> </segment>   <segment state=”translated”>                <source>hello</source>                <target>halló</target> </segment>   Second handoff:   <segment state=”translated” subState=”xy:sourceUpdate”>                <source>hello world</source>                <target>halló</target> </segment>   <segment state=”translated” subState=”xy:sourceUpdate”>                <source>hello world</source>                <target>halló veröld</target> </segment>   <segment state=”reviewed” subState=”xy:sourceUpdate”>                <source>hello world</source>                <target>halló veröld</target> </segment>     If I understand ms:sourceUpdate, I could clear subState after setting the state to “reviewed”, however, if I don’t understand ms:sourceUpdate, couldn’t I treat it like any other extension (it is after all a type of extensibility) and just ignore it but preserve it? It could very well be that the content provider that owns xy:sourceUpdate wants to know that a particular handed-back <segment>, which was updated, was indeed re-translated and reviewed.  The advantage to a xlf:subState over some arbitrary extension such as xy:subState is that editors, for example, could relate it and display it with xlf:state in a consistent manner because Processing Instructions state: If the attribute subtype is used, the attribute type must be specified as well.     From: David Filip [ mailto:davidf@davidf.org ] Sent: Thursday, May 30, 2013 5:02 AM To: Yves Savourel; Ryan King Cc: xliff-comment@lists.oasis-open.org Subject: Re: [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype processing requirements   I think the update/drop of sub* should be enforced throughout the sub* attributes..   If you own the subtype, it is easy to know the invisible update, I would not be worried with that. The PR is important to those who do not know the predefined subproperties. If you cannot update, you MUST drop.. *Something* MUST be done to subproperty if property changed..     David Filip, Ph.D. ===================== cellphone: +353-86-0222-158 mailto: davidf@davidf.org www.davidf.org , http://www.linkedin.com/in/davidfatdavidf   On Wed, May 29, 2013 at 7:15 PM, Yves Savourel < yves@opentag.com > wrote: I tend to agree.     From: Ryan King [mailto: ryanki@microsoft.com ] Sent: Wednesday, May 29, 2013 11:19 AM To: Yves Savourel; xliff-comment@lists.oasis-open.org Subject: RE: [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype processing requirements   All of the sub properties already have the a similar PR to the following:   ·         If the attribute subtype is used, the attribute type must be specified as well.   So if your statement  “I think this PR comes from the constraint that you should not have a subtype without a type, therefore the subtype is linked to the type (it complements it).” applies to subType in <mtc:matches> shouldn’t it also apply to all sub attributes: 2.3.1.34 subType, 2.3.1.35 subState, D.1.2.2 subFs? I think it should be all or nothing to avoid confusion, or maybe just the PR noted above is enough to show the relationship?   Ryan       From: Yves Savourel [ mailto:yves@opentag.com ] Sent: Wednesday, May 29, 2013 3:47 AM To: xliff-comment@lists.oasis-open.org Subject: RE: [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype processing requirements   I think this PR comes from the constraint that you should not have a subtype without a type, therefore the subtype is linked to the type (it complements it). In your example, if a type can have the same subtype value you can have an “invisible” update: the updated subtype value simply happens to have the same value as before.   -ys   From: Ryan King [ mailto:ryanki@microsoft.com ] Sent: Wednesday, May 29, 2013 2:05 AM To: xliff-comment@lists.oasis-open.org Cc: xliff@lists.oasis-open.org Subject: [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype processing requirements   B.1.3.7 subtype processing requirements state:   If the attribute type is modified, the attribute subtype must be updated or deleted.   Is this always the case? What if I have a two types, e.g. “tm” and “mt”, that have the same subType? If my type changes from “tm” to “mt” there may be no reason for me to update or delete the subState. Was there a particular reason for this processing requirement? Similar sub attributes…   2.3.1.34 subType 2.3.1.35 subState D.1.2.2 subFs   …do not have this requirement.   Thanks, Ryan      


  • 12.  RE: [xliff] Re: [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype processing requirements

    Posted 05-31-2013 17:01
    Hi David,

    I think Chet was mentioning this only about my note on the interpretation of the implementation requirements.

    Comments on the draft should be done on the comment list
    https://www.oasis-open.org/policies-guidelines/tc-process#publicReview
    (with the exception that TC members can also comment in the TC list)

    IMO any comment should be done in the comment list (even from a TC member) and the discussion and disposal of it in there too,
    otherwise how can commenters participate?

    (I'm also getting tired to get 3 copies of the same email)

    Cheers,
    -ys


    From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of David Filip
    Sent: Friday, May 31, 2013 10:46 AM
    To: Ryan King; xliff@lists.oasis-open.org
    Cc: Josep Condal; Yves Savourel; xliff-comment@lists.oasis-open.org
    Subject: [xliff] Re: [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype processing requirements

    Guys, Chet, pointed out in another conversation that the comment list is not intended for discussions.
    This discussion either has to happen between Ryan and Josep and Ryan can update the TC on the result.
    Or, Josep, we cordially invite you to join the TC :-) and continue the discussion on the TC list

    Rgds
    dF


    David Filip, Ph.D.
    =====================
    cellphone: +353-86-0222-158
    mailto:davidf@davidf.org
    www.davidf.org, http://www.linkedin.com/in/davidfatdavidf

    On Thu, May 30, 2013 at 7:32 PM, Ryan King <ryanki@microsoft.com> wrote:
    Thank you Josep for pointing this out. I agree with your logic on this point. In my original example, tools aware of xy:sourceUpdate
    could alert a translator to review and possibly re-translate the segment whether the state is translated or initial. However, tools
    not aware of xy:sourceUpdate would need to rely on state alone, and therefore, your example makes more sense here.
     
    From: Josep Condal [mailto:pcondal@apsic.com]
    Sent: Thursday, May 30, 2013 11:21 AM
    To: Ryan King; David Filip; Yves Savourel
    Cc: xliff-comment@lists.oasis-open.org

    Subject: RE: [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype processing requirements
     
    Ryan,
     
    An unrelated comment to this thread (but I think that yet important to point out) is that for the second handoff, the logical state
    of the changed segment should be reverted back to "initial", regardless of if <target> is primed with something potentially useful
    (or not) for the translator. 
     
    Otherwise it will not be possible for a tool to tell if it makes sense to consider the segment as really translated or not. Please
    note that there are no differences in attributes for the first two stages of the second handoff, and tools cannot (yet)
    understand natural language well enough to infer the state of the segment in the same way a human being could do it.
     
    <segment state=?initial? subState=?xy:sourceUpdate?>
                   hello world
                   <target>halló</target>
    </segment>
     
    Regards,
    Josep.
     
     
    ________________________________________
    De: Ryan King [mailto:ryanki@microsoft.com]
    Enviado el: jueves, 30 de mayo de 2013 19:15
    Para: David Filip; Yves Savourel
    CC: xliff-comment@lists.oasis-open.org
    Asunto: RE: [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype processing requirements
    >> If you cannot update, you MUST drop.. *Something* MUST be done to subproperty if property changed..
     
    I?m not totally convinced that it MUST be dropped. As an example:
     
    First handoff:
     
    <segment state=?initial?>
                   hello
    </segment>
     
    <segment state=?translated?>
                   hello
                   <target>halló</target>
    </segment>
     
    Second handoff:
     
    <segment state=?translated? subState=?xy:sourceUpdate?>
                   hello world
                   <target>halló</target>
    </segment>
     
    <segment state=?translated? subState=?xy:sourceUpdate?>
                   hello world
                   <target>halló veröld</target>
    </segment>
     
    <segment state=?reviewed? subState=?xy:sourceUpdate?>
                   hello world
                   <target>halló veröld</target>
    </segment>
     
     
    If I understand ms:sourceUpdate, I could clear subState after setting the state to ?reviewed?, however, if I don?t understand
    ms:sourceUpdate, couldn?t I treat it like any other extension (it is after all a type of extensibility) and just ignore it but
    preserve it? It could very well be that the content provider that owns xy:sourceUpdate wants to know that a particular handed-back
    <segment>, which was updated, was indeed re-translated and reviewed.  The advantage to a xlf:subState over some arbitrary extension
    such as xy:subState is that editors, for example, could relate it and display it with xlf:state in a consistent manner because
    Processing Instructions state: If the attribute subtype is used, the attribute type must be specified as well.
     
     
    From: David Filip [mailto:davidf@davidf.org]
    Sent: Thursday, May 30, 2013 5:02 AM
    To: Yves Savourel; Ryan King
    Cc: xliff-comment@lists.oasis-open.org
    Subject: Re: [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype processing requirements
     
    I think the update/drop of sub* should be enforced throughout the sub* attributes..
     
    If you own the subtype, it is easy to know the invisible update, I would not be worried with that.
    The PR is important to those who do not know the predefined subproperties.
    If you cannot update, you MUST drop.. *Something* MUST be done to subproperty if property changed..
     
     
    David Filip, Ph.D.
    =====================
    cellphone: +353-86-0222-158
    mailto:davidf@davidf.org
    www.davidf.org, http://www.linkedin.com/in/davidfatdavidf
     
    On Wed, May 29, 2013 at 7:15 PM, Yves Savourel <yves@opentag.com> wrote:
    I tend to agree.
     
     
    From: Ryan King [mailto:ryanki@microsoft.com]
    Sent: Wednesday, May 29, 2013 11:19 AM
    To: Yves Savourel; xliff-comment@lists.oasis-open.org

    Subject: RE: [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype processing requirements
     
    All of the sub properties already have the a similar PR to the following:
     
    ?        If the attribute subtype is used, the attribute type must be specified as well.
     
    So if your statement  ?I think this PR comes from the constraint that you should not have a subtype without a type, therefore the
    subtype is linked to the type (it complements it).? applies to subType in <mtc:matches> shouldn?t it also apply to all sub
    attributes: 2.3.1.34 subType, 2.3.1.35 subState, D.1.2.2 subFs? I think it should be all or nothing to avoid confusion, or maybe
    just the PR noted above is enough to show the relationship?
     
    Ryan
     
     
     
    From: Yves Savourel [mailto:yves@opentag.com]
    Sent: Wednesday, May 29, 2013 3:47 AM
    To: xliff-comment@lists.oasis-open.org
    Subject: RE: [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype processing requirements
     
    I think this PR comes from the constraint that you should not have a subtype without a type, therefore the subtype is linked to the
    type (it complements it).
    In your example, if a type can have the same subtype value you can have an ?invisible? update: the updated subtype value simply
    happens to have the same value as before.
     
    -ys
     
    From: Ryan King [mailto:ryanki@microsoft.com]
    Sent: Wednesday, May 29, 2013 2:05 AM
    To: xliff-comment@lists.oasis-open.org
    Cc: xliff@lists.oasis-open.org
    Subject: [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype processing requirements
     
    B.1.3.7 subtype processing requirements state:
     
    If the attribute type is modified, the attribute subtype must be updated or deleted.
     
    Is this always the case? What if I have a two types, e.g. ?tm? and ?mt?, that have the same subType? If my type changes from ?tm? to
    ?mt? there may be no reason for me to update or delete the subState. Was there a particular reason for this processing requirement?
    Similar sub attributes?
     
    2.3.1.34 subType
    2.3.1.35 subState
    D.1.2.2 subFs
     
    ?do not have this requirement.
     
    Thanks,
    Ryan
     
     
     





  • 13.  RE: [xliff-comment] RE: [xliff] Re: [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype processing requirements

    Posted 05-31-2013 17:51
    Hi Yves,

    Thank you for clarifying that it is probably a misundertanding.

    It's a bit of a relief, because having a natural trend of being a "duct tape" kind of guy, I'm a bit generalist so I do not feel I have the right profile for the TC to make meaningful contributions on an ongoing basis (my role in ApSIC Xbench is product management, not really development).

    I'm flattered for the invitation to join the TC, but unfortunately I have to decline. Still, I hope that some ocasional comment dropped by me in this list can be useful and/or provide feedback to the TC from other implementors points of view.

    Regards,
    Josep.

    -----Mensaje original-----
    De: Yves Savourel [mailto:yves@opentag.com]
    Enviado el: viernes, 31 de mayo de 2013 19:01
    Para: xliff-comment@lists.oasis-open.org
    Asunto: [xliff-comment] RE: [xliff] Re: [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype processing requirements

    Hi David,

    I think Chet was mentioning this only about my note on the interpretation of the implementation requirements.

    Comments on the draft should be done on the comment list https://www.oasis-open.org/policies-guidelines/tc-process#publicReview
    (with the exception that TC members can also comment in the TC list)

    IMO any comment should be done in the comment list (even from a TC member) and the discussion and disposal of it in there too, otherwise how can commenters participate?

    (I'm also getting tired to get 3 copies of the same email)

    Cheers,
    -ys


    From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of David Filip
    Sent: Friday, May 31, 2013 10:46 AM
    To: Ryan King; xliff@lists.oasis-open.org
    Cc: Josep Condal; Yves Savourel; xliff-comment@lists.oasis-open.org
    Subject: [xliff] Re: [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype processing requirements

    Guys, Chet, pointed out in another conversation that the comment list is not intended for discussions.
    This discussion either has to happen between Ryan and Josep and Ryan can update the TC on the result.
    Or, Josep, we cordially invite you to join the TC :-) and continue the discussion on the TC list

    Rgds
    dF


    David Filip, Ph.D.
    =====================
    cellphone: +353-86-0222-158
    mailto:davidf@davidf.org
    www.davidf.org, http://www.linkedin.com/in/davidfatdavidf

    On Thu, May 30, 2013 at 7:32 PM, Ryan King <ryanki@microsoft.com> wrote:
    Thank you Josep for pointing this out. I agree with your logic on this point. In my original example, tools aware of xy:sourceUpdate could alert a translator to review and possibly re-translate the segment whether the state is translated or initial. However, tools not aware of xy:sourceUpdate would need to rely on state alone, and therefore, your example makes more sense here.
     
    From: Josep Condal [mailto:pcondal@apsic.com]
    Sent: Thursday, May 30, 2013 11:21 AM
    To: Ryan King; David Filip; Yves Savourel
    Cc: xliff-comment@lists.oasis-open.org

    Subject: RE: [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype processing requirements
     
    Ryan,
     
    An unrelated comment to this thread (but I think that yet important to point out) is that for the second handoff, the logical state of the changed segment should be reverted back to "initial", regardless of if <target> is primed with something potentially useful (or not) for the translator. 
     
    Otherwise it will not be possible for a tool to tell if it makes sense to consider the segment as really translated or not. Please note that there are no differences in attributes for the first two stages of the second handoff, and tools cannot (yet) understand natural language well enough to infer the state of the segment in the same way a human being could do it.
     
    <segment state="initial" subState="xy:sourceUpdate">
                   hello world
                   <target>halló</target>
    </segment>
     
    Regards,
    Josep.
     
     
    ________________________________________
    De: Ryan King [mailto:ryanki@microsoft.com] Enviado el: jueves, 30 de mayo de 2013 19:15
    Para: David Filip; Yves Savourel
    CC: xliff-comment@lists.oasis-open.org
    Asunto: RE: [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype processing requirements
    >> If you cannot update, you MUST drop.. *Something* MUST be done to subproperty if property changed..
     
    I'm not totally convinced that it MUST be dropped. As an example:
     
    First handoff:
     
    <segment state="initial">
                   hello
    </segment>
     
    <segment state="translated">
                   hello
                   <target>halló</target>
    </segment>
     
    Second handoff:
     
    <segment state="translated" subState="xy:sourceUpdate">
                   hello world
                   <target>halló</target>
    </segment>
     
    <segment state="translated" subState="xy:sourceUpdate">
                   hello world
                   <target>halló veröld</target> </segment>
     
    <segment state="reviewed" subState="xy:sourceUpdate">
                   hello world
                   <target>halló veröld</target> </segment>
     
     
    If I understand ms:sourceUpdate, I could clear subState after setting the state to "reviewed", however, if I don't understand ms:sourceUpdate, couldn't I treat it like any other extension (it is after all a type of extensibility) and just ignore it but preserve it? It could very well be that the content provider that owns xy:sourceUpdate wants to know that a particular handed-back <segment>, which was updated, was indeed re-translated and reviewed.  The advantage to a xlf:subState over some arbitrary extension such as xy:subState is that editors, for example, could relate it and display it with xlf:state in a consistent manner because Processing Instructions state: If the attribute subtype is used, the attribute type must be specified as well.
     
     
    From: David Filip [mailto:davidf@davidf.org]
    Sent: Thursday, May 30, 2013 5:02 AM
    To: Yves Savourel; Ryan King
    Cc: xliff-comment@lists.oasis-open.org
    Subject: Re: [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype processing requirements
     
    I think the update/drop of sub* should be enforced throughout the sub* attributes..
     
    If you own the subtype, it is easy to know the invisible update, I would not be worried with that.
    The PR is important to those who do not know the predefined subproperties.
    If you cannot update, you MUST drop.. *Something* MUST be done to subproperty if property changed..
     
     
    David Filip, Ph.D.
    =====================
    cellphone: +353-86-0222-158
    mailto:davidf@davidf.org
    www.davidf.org, http://www.linkedin.com/in/davidfatdavidf
     
    On Wed, May 29, 2013 at 7:15 PM, Yves Savourel <yves@opentag.com> wrote:
    I tend to agree.
     
     
    From: Ryan King [mailto:ryanki@microsoft.com]
    Sent: Wednesday, May 29, 2013 11:19 AM
    To: Yves Savourel; xliff-comment@lists.oasis-open.org

    Subject: RE: [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype processing requirements
     
    All of the sub properties already have the a similar PR to the following:
     
    .        If the attribute subtype is used, the attribute type must be specified as well.
     
    So if your statement  "I think this PR comes from the constraint that you should not have a subtype without a type, therefore the subtype is linked to the type (it complements it)." applies to subType in <mtc:matches> shouldn't it also apply to all sub
    attributes: 2.3.1.34 subType, 2.3.1.35 subState, D.1.2.2 subFs? I think it should be all or nothing to avoid confusion, or maybe just the PR noted above is enough to show the relationship?
     
    Ryan
     
     
     
    From: Yves Savourel [mailto:yves@opentag.com]
    Sent: Wednesday, May 29, 2013 3:47 AM
    To: xliff-comment@lists.oasis-open.org
    Subject: RE: [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype processing requirements
     
    I think this PR comes from the constraint that you should not have a subtype without a type, therefore the subtype is linked to the type (it complements it).
    In your example, if a type can have the same subtype value you can have an "invisible" update: the updated subtype value simply happens to have the same value as before.
     
    -ys
     
    From: Ryan King [mailto:ryanki@microsoft.com]
    Sent: Wednesday, May 29, 2013 2:05 AM
    To: xliff-comment@lists.oasis-open.org
    Cc: xliff@lists.oasis-open.org
    Subject: [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype processing requirements
     
    B.1.3.7 subtype processing requirements state:
     
    If the attribute type is modified, the attribute subtype must be updated or deleted.
     
    Is this always the case? What if I have a two types, e.g. "tm" and "mt", that have the same subType? If my type changes from "tm" to "mt" there may be no reason for me to update or delete the subState. Was there a particular reason for this processing requirement?
    Similar sub attributes.
     
    2.3.1.34 subType
    2.3.1.35 subState
    D.1.2.2 subFs
     
    .do not have this requirement.
     
    Thanks,
    Ryan
     
     
     



    --
    This publicly archived list offers a means to provide input to the OASIS XML Localisation Interchange File Format (XLIFF) TC.

    In order to verify user consent to the Feedback License terms and to minimize spam in the list archive, subscription is required before posting.

    Subscribe: xliff-comment-subscribe@lists.oasis-open.org
    Unsubscribe: xliff-comment-unsubscribe@lists.oasis-open.org
    List help: xliff-comment-help@lists.oasis-open.org
    List archive: http://lists.oasis-open.org/archives/xliff-comment/
    Feedback License: http://www.oasis-open.org/who/ipr/feedback_license.pdf
    List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
    Committee: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xliff
    Join OASIS: http://www.oasis-open.org/join/