OASIS XML Localisation Interchange File Format (XLIFF) TC

  • 1.  [xliff]

    Posted 02-02-2016 19:40
    Hi David, Patrik logged a bug for this against the MS XLIFF 2.0 OM on GitHub. Can you verify when and if the PR will be added to the 2.0 spec? We do not want to fix it as a bug in the OM validator unless it is reflective of what is actually in the spec. Thanks, Ryan  From: David Filip [mailto:david.filip@adaptcentre.ie] Sent: Thursday, December 17, 2015 3:01 PM To: Patrik Mazanek <pmazanek@sdl.com> Cc: XLIFF Main List <xliff@lists.oasis-open.org> Subject: Re: [xliff] <sm/> and <em/>   Thanks, Patrik, there was a discussion on this back in summer 2014.   While orphaned <sc/> and <ec/> are possible and allowed because XLIFF Agents are not in control of the native markup in the original and target format.   Now, XLIFF Agents are always in control of annotations. The <mrk> and <sm/>/<em/> behave largely analogically to <pc> and <sc/>/<ec/> except that they don't have attributes and Constraints and PRs to handle orphaned cases. It follows implicitly that orphaned <sm/> or <em/> are not allowed in a scope of any <unit>. I guess the Okapi and MSFT OM don't catch this, as there is no explicit Constraint or PR to prohibit that. I would suggest that we add such PR, as it wouldn't be really chanhing the spec materially, just adding explicit wording to what otherwise follows implicitly.   Cheers 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 Thu, Dec 17, 2015 at 1:49 PM, Patrik Mazanek < pmazanek@sdl.com > wrote: HI, I wanted to ask about <sm/> and <em/> tags. In specification it is said that the marker can be created by using <mrk> tag pair , or the pair of <sm> and <em> elements. What it doesn’t say if you can have situation where only <sm/> or <em/> is present, e.g.:   <xliff xmlns="urn:oasis:names:tc:xliff:document:2.0" xmlns:fs="urn:oasis:names:tc:xliff:fs:2.0" xmlns:slr="urn:oasis:names:tc:xliff:sizerestriction:2.0" version="2.0" xml:space="preserve" srcLang="en-GB" trgLang="fr-FR">     <file id="f1" original="myfile">         <unit id="1">             <segment id="id1" >                <source>Example of an sm with  <sm id="2" type="term"/> term</source>             </segment>         </unit>     </file> </xliff>   It seems both Okapi validator and MS XLIFF OM validate the example above as valid file. If this is indeed correct I believe we should enhance the specification and make sure this bit is explained a bit better.   Regards   Patrik Mazanek   l   Product Owner – Translation productivity l   SDL   l   Language Technologies Division   l   (T) +49 (0)1520 9098850 l   (F)   +49 711 780 4197  


  • 2.  RE: [xliff]

    Posted 02-23-2016 01:15
    Hi David, apologies if you already answered and I missed it. Can you clarify my question below?   Thanks, Ryan   From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Ryan King Sent: Tuesday, February 2, 2016 11:40 AM To: 'xliff@lists.oasis-open.org' <xliff@lists.oasis-open.org> Subject: [xliff] <sm/> and <em/>   Hi David, Patrik logged a bug for this against the MS XLIFF 2.0 OM on GitHub. Can you verify when and if the PR will be added to the 2.0 spec? We do not want to fix it as a bug in the OM validator unless it is reflective of what is actually in the spec. Thanks, Ryan  From: David Filip [ mailto:david.filip@adaptcentre.ie ] Sent: Thursday, December 17, 2015 3:01 PM To: Patrik Mazanek < pmazanek@sdl.com > Cc: XLIFF Main List < xliff@lists.oasis-open.org > Subject: Re: [xliff] <sm/> and <em/>   Thanks, Patrik, there was a discussion on this back in summer 2014.   While orphaned <sc/> and <ec/> are possible and allowed because XLIFF Agents are not in control of the native markup in the original and target format.   Now, XLIFF Agents are always in control of annotations. The <mrk> and <sm/>/<em/> behave largely analogically to <pc> and <sc/>/<ec/> except that they don't have attributes and Constraints and PRs to handle orphaned cases. It follows implicitly that orphaned <sm/> or <em/> are not allowed in a scope of any <unit>. I guess the Okapi and MSFT OM don't catch this, as there is no explicit Constraint or PR to prohibit that. I would suggest that we add such PR, as it wouldn't be really chanhing the spec materially, just adding explicit wording to what otherwise follows implicitly.   Cheers 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 Thu, Dec 17, 2015 at 1:49 PM, Patrik Mazanek < pmazanek@sdl.com > wrote: HI, I wanted to ask about <sm/> and <em/> tags. In specification it is said that the marker can be created by using <mrk> tag pair , or the pair of <sm> and <em> elements. What it doesn’t say if you can have situation where only <sm/> or <em/> is present, e.g.:   <xliff xmlns="urn:oasis:names:tc:xliff:document:2.0" xmlns:fs="urn:oasis:names:tc:xliff:fs:2.0" xmlns:slr="urn:oasis:names:tc:xliff:sizerestriction:2.0" version="2.0" xml:space="preserve" srcLang="en-GB" trgLang="fr-FR">     <file id="f1" original="myfile">         <unit id="1">             <segment id="id1" >                <source>Example of an sm with  <sm id="2" type="term"/> term</source>             </segment>         </unit>     </file> </xliff>   It seems both Okapi validator and MS XLIFF OM validate the example above as valid file. If this is indeed correct I believe we should enhance the specification and make sure this bit is explained a bit better.   Regards   Patrik Mazanek   l   Product Owner – Translation productivity l   SDL   l   Language Technologies Division   l   (T) +49 (0)1520 9098850 l   (F)   +49 711 780 4197  


  • 3.  RE: [xliff]

    Posted 02-23-2016 02:03
    Hi Ryan, apologies, I haven't answered yet. We discussed this in the last TC and Fredrik took the action item to answer with a spec reference. In short, the spec says that annotations are either mrk or pairs of sm / em. Fredrik will provide the reference. isolated doesn't exist, by design, on sm / em, so really there is no mechanism to make orphaned annotations, and hence no need for an explicit Constraint prohibiting them. Finally, I want to clarify - and I said the same in the last meeting (not sure if the minutes are out yet) - that it is impossible to change XLIFF 2.0. The OASIS process has produced XLIFF 2.0, which is now immutable, "set in stone" if you wish. This is true for any OASIS Standard and in fact for any numbered draft of any OASIS standard work product, starting with cs01. Anyways, OASIS Standard is the last state of the OASIS state machine; editorial fixes can be pushed through Errata. But to amend anything you need to "deprecate" the old standard with producing a new standard that replaces and supersedes the older version.. We agreed not to spend time and effort on producing Errata. Instead, where core seems unclear or open to more than 1 interpretation, we are free (and have agreed) to add more clarity when restating the core in 2.1. IMHO, we don't need an explicit Constraint saying that orphaned sm / em are invalid. But at the same time, if the TC agrees that having such an explicit Constraint brings more clarity, I think there is no issue with having it in 2.1. It doesn't constitute a material or logical change compared to what 2.0 core states, IMHO and AFAIK. Personally, I believe that it would be enough to add a Note and invalid test suite files with orphaned sm and em. BTW, we are free to maintain / amend the 2.0 test suite, as the test suite is not a formal part of the multi-part work product; merely an implementation aid that the TC promised to provide.. I hope this helps Cheers dF On Feb 23, 2016 02:15, "Ryan King" < ryanki@microsoft.com > wrote: Hi David, apologies if you already answered and I missed it. Can you clarify my question below?   Thanks, Ryan   From: xliff@lists.oasis-open.org [mailto: xliff@lists.oasis-open.org ] On Behalf Of Ryan King Sent: Tuesday, February 2, 2016 11:40 AM To: ' xliff@lists.oasis-open.org ' < xliff@lists.oasis-open.org > Subject: [xliff] <sm/> and <em/>   Hi David, Patrik logged a bug for this against the MS XLIFF 2.0 OM on GitHub. Can you verify when and if the PR will be added to the 2.0 spec? We do not want to fix it as a bug in the OM validator unless it is reflective of what is actually in the spec. Thanks, Ryan  From: David Filip [ mailto:david.filip@adaptcentre.ie ] Sent: Thursday, December 17, 2015 3:01 PM To: Patrik Mazanek < pmazanek@sdl.com > Cc: XLIFF Main List < xliff@lists.oasis-open.org > Subject: Re: [xliff] <sm/> and <em/>   Thanks, Patrik, there was a discussion on this back in summer 2014.   While orphaned <sc/> and <ec/> are possible and allowed because XLIFF Agents are not in control of the native markup in the original and target format.   Now, XLIFF Agents are always in control of annotations. The <mrk> and <sm/>/<em/> behave largely analogically to <pc> and <sc/>/<ec/> except that they don't have attributes and Constraints and PRs to handle orphaned cases. It follows implicitly that orphaned <sm/> or <em/> are not allowed in a scope of any <unit>. I guess the Okapi and MSFT OM don't catch this, as there is no explicit Constraint or PR to prohibit that. I would suggest that we add such PR, as it wouldn't be really chanhing the spec materially, just adding explicit wording to what otherwise follows implicitly.   Cheers 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 Thu, Dec 17, 2015 at 1:49 PM, Patrik Mazanek < pmazanek@sdl.com > wrote: HI, I wanted to ask about <sm/> and <em/> tags. In specification it is said that the marker can be created by using <mrk> tag pair , or the pair of <sm> and <em> elements. What it doesn’t say if you can have situation where only <sm/> or <em/> is present, e.g.:   <xliff xmlns="urn:oasis:names:tc:xliff:document:2.0" xmlns:fs="urn:oasis:names:tc:xliff:fs:2.0" xmlns:slr="urn:oasis:names:tc:xliff:sizerestriction:2.0" version="2.0" xml:space="preserve" srcLang="en-GB" trgLang="fr-FR">     <file id="f1" original="myfile">         <unit id="1">             <segment id="id1" >                <source>Example of an sm with  <sm id="2" type="term"/> term</source>             </segment>         </unit>     </file> </xliff>   It seems both Okapi validator and MS XLIFF OM validate the example above as valid file. If this is indeed correct I believe we should enhance the specification and make sure this bit is explained a bit better.   Regards   Patrik Mazanek   l   Product Owner – Translation productivity l   SDL   l   Language Technologies Division   l   (T) +49 (0)1520 9098850 l   (F)   +49 711 780 4197  


  • 4.  RE: [xliff]

    Posted 02-23-2016 17:43




    Thanks, David, I understand (and agree with) the rigidity of the 2.0 standard. So, if I understand your intent below, is it fair to say that most likely because of this section:
    4.7.3.2 Splitting Annotations
    Orphan <sm> and <em> are not allowed because:

    1)      
    As stated in that section: Annotations can overlap spanning inline codes or other annotations. They also can be split by segmentation. Because of this,
    **a single** annotation span can be represented using **a pair** of
    <sm> and
    <em> elements instead of a single
    <mrk> element.

    2)      
    It is, therefore, implicitly understood that orphaning is not allowed because of the asterisks added above and the fact that there is no further mention
    of how to deal with orphaned tags.
     
    Is that correct?
     
    Thanks,
    Ryan
     
    From: David Filip [mailto:david.filip@adaptcentre.ie]

    Sent: Monday, February 22, 2016 6:03 PM
    To: Ryan King <ryanki@microsoft.com>
    Cc: XLIFF Main List <xliff@lists.oasis-open.org>
    Subject: RE: [xliff] <sm/> and <em/>
     
    Hi Ryan, apologies, I haven't answered yet.
    We discussed this in the last TC and Fredrik took the action item to answer with a spec reference.

    In short, the spec says that annotations are either mrk or pairs of sm / em.
    Fredrik will provide the reference.
    isolated doesn't exist, by design, on sm / em, so really there is no mechanism to make orphaned annotations, and hence no need for an explicit Constraint prohibiting them.
    Finally, I want to clarify - and I said the same in the last meeting (not sure if the minutes are out yet) - that it is impossible to change XLIFF 2.0.
    The OASIS process has produced XLIFF 2.0, which is now immutable, "set in stone" if you wish. This is true for any OASIS Standard and in fact for any numbered draft of any OASIS standard work product, starting with cs01. Anyways, OASIS Standard is the last
    state of the OASIS state machine; editorial fixes can be pushed through Errata. But to amend anything you need to "deprecate" the old standard with producing a new standard that replaces and supersedes the older version..

    We agreed not to spend time and effort on producing Errata.
    Instead, where core seems unclear or open to more than 1 interpretation, we are free (and have agreed) to add more clarity when restating the core in 2.1.

    IMHO, we don't need an explicit Constraint saying that orphaned sm / em are invalid.

    But at the same time, if the TC agrees that having such an explicit Constraint brings more clarity, I think there is no issue with having it in 2.1. It doesn't constitute a material or logical change compared to what 2.0 core states, IMHO and AFAIK.

    Personally, I believe that it would be enough to add a Note and invalid test suite files with orphaned sm and em. BTW, we are free to maintain / amend the 2.0 test suite, as the test suite is not a formal part of the multi-part work product; merely an implementation
    aid that the TC promised to provide..
    I hope this helps
    Cheers
    dF

    On Feb 23, 2016 02:15, "Ryan King" < ryanki@microsoft.com > wrote:



    Hi David, apologies if you already answered and I missed it. Can you clarify my question below?
     
    Thanks,
    Ryan
     


    From:
    xliff@lists.oasis-open.org [mailto: xliff@lists.oasis-open.org ]
    On Behalf Of Ryan King
    Sent: Tuesday, February 2, 2016 11:40 AM
    To: ' xliff@lists.oasis-open.org ' < xliff@lists.oasis-open.org >
    Subject: [xliff] <sm/> and <em/>


     




    Hi David, Patrik logged a bug for this against the MS XLIFF 2.0 OM on GitHub. Can you verify when and if the PR will be added to the 2.0 spec? We do
    not want to fix it as a bug in the OM validator unless it is reflective of what is actually in the spec.
    Thanks,
    Ryan 
    From: David Filip [ mailto:david.filip@adaptcentre.ie ]

    Sent: Thursday, December 17, 2015 3:01 PM
    To: Patrik Mazanek < pmazanek@sdl.com >
    Cc: XLIFF Main List < xliff@lists.oasis-open.org >
    Subject: Re: [xliff] <sm/> and <em/>
     
    Thanks, Patrik, there was a discussion on this back in summer 2014.
     
    While orphaned <sc/> and <ec/> are possible and allowed because XLIFF Agents are not in control of the native markup in the original and target format.
     
    Now, XLIFF Agents are always in control of annotations. The <mrk> and <sm/>/<em/> behave largely analogically to <pc> and <sc/>/<ec/> except that they don't have attributes and
    Constraints and PRs to handle orphaned cases.
    It follows implicitly that orphaned <sm/> or <em/> are not allowed in a scope of any <unit>.
    I guess the Okapi and MSFT OM don't catch this, as there is no explicit Constraint or PR to prohibit that.
    I would suggest that we add such PR, as it wouldn't be really chanhing the spec materially, just adding explicit wording to what otherwise follows implicitly.
     
    Cheers
    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 Thu, Dec 17, 2015 at 1:49 PM, Patrik Mazanek < pmazanek@sdl.com > wrote:
    HI,
    I wanted to ask about <sm/> and <em/> tags. In specification it is said that the marker can be created by using <mrk> tag pair , or the pair of <sm> and <em> elements. What it doesn’t
    say if you can have situation where only <sm/> or <em/> is present, e.g.:
     
    <xliff xmlns="urn:oasis:names:tc:xliff:document:2.0" xmlns:fs="urn:oasis:names:tc:xliff:fs:2.0" xmlns:slr="urn:oasis:names:tc:xliff:sizerestriction:2.0" version="2.0" xml:space="preserve"
    srcLang="en-GB" trgLang="fr-FR">
        <file id="f1" original="myfile">
            <unit id="1">
                <segment id="id1" >
                   <source>Example of an sm with  <sm id="2" type="term"/> term</source>
                </segment>
            </unit>
        </file>
    </xliff>
     
    It seems both Okapi validator and MS XLIFF OM validate the example above as valid file. If this is indeed correct I believe we should enhance the specification and make sure this
    bit is explained a bit better.
     
    Regards
     
    Patrik Mazanek  
    l  
    Product Owner – Translation productivity
    l
      SDL
      l  
    Language Technologies Division  
    l  
    (T)
    +49 (0)1520 9098850
    l  
    (F)   +49 711 780 4197




     










  • 5.  Re: [xliff]

    Posted 02-23-2016 17:57
    Thanks, Ryan, IMHO that's correct. Only a pair of <sm> <em> can form an annotation span as per the highlighted 2.0 section. I am open to discussing how to make this clearer in 2.1. Cheers 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 Tue, Feb 23, 2016 at 5:43 PM, Ryan King < ryanki@microsoft.com > wrote: Thanks, David, I understand (and agree with) the rigidity of the 2.0 standard. So, if I understand your intent below, is it fair to say that most likely because of this section: 4.7.3.2 Splitting Annotations Orphan <sm> and <em> are not allowed because: 1)       As stated in that section: Annotations can overlap spanning inline codes or other annotations. They also can be split by segmentation. Because of this, **a single** annotation span can be represented using **a pair** of <sm> and <em> elements instead of a single <mrk> element. 2)       It is, therefore, implicitly understood that orphaning is not allowed because of the asterisks added above and the fact that there is no further mention of how to deal with orphaned tags.   Is that correct?   Thanks, Ryan   From: David Filip [mailto: david.filip@adaptcentre.ie ] Sent: Monday, February 22, 2016 6:03 PM To: Ryan King < ryanki@microsoft.com > Cc: XLIFF Main List < xliff@lists.oasis-open.org > Subject: RE: [xliff] <sm/> and <em/>   Hi Ryan, apologies, I haven't answered yet. We discussed this in the last TC and Fredrik took the action item to answer with a spec reference. In short, the spec says that annotations are either mrk or pairs of sm / em. Fredrik will provide the reference. isolated doesn't exist, by design, on sm / em, so really there is no mechanism to make orphaned annotations, and hence no need for an explicit Constraint prohibiting them. Finally, I want to clarify - and I said the same in the last meeting (not sure if the minutes are out yet) - that it is impossible to change XLIFF 2.0. The OASIS process has produced XLIFF 2.0, which is now immutable, "set in stone" if you wish. This is true for any OASIS Standard and in fact for any numbered draft of any OASIS standard work product, starting with cs01. Anyways, OASIS Standard is the last state of the OASIS state machine; editorial fixes can be pushed through Errata. But to amend anything you need to "deprecate" the old standard with producing a new standard that replaces and supersedes the older version.. We agreed not to spend time and effort on producing Errata. Instead, where core seems unclear or open to more than 1 interpretation, we are free (and have agreed) to add more clarity when restating the core in 2.1. IMHO, we don't need an explicit Constraint saying that orphaned sm / em are invalid. But at the same time, if the TC agrees that having such an explicit Constraint brings more clarity, I think there is no issue with having it in 2.1. It doesn't constitute a material or logical change compared to what 2.0 core states, IMHO and AFAIK. Personally, I believe that it would be enough to add a Note and invalid test suite files with orphaned sm and em. BTW, we are free to maintain / amend the 2.0 test suite, as the test suite is not a formal part of the multi-part work product; merely an implementation aid that the TC promised to provide.. I hope this helps Cheers dF On Feb 23, 2016 02:15, "Ryan King" < ryanki@microsoft.com > wrote: Hi David, apologies if you already answered and I missed it. Can you clarify my question below?   Thanks, Ryan   From: xliff@lists.oasis-open.org [mailto: xliff@lists.oasis-open.org ] On Behalf Of Ryan King Sent: Tuesday, February 2, 2016 11:40 AM To: ' xliff@lists.oasis-open.org ' < xliff@lists.oasis-open.org > Subject: [xliff] <sm/> and <em/>   Hi David, Patrik logged a bug for this against the MS XLIFF 2.0 OM on GitHub. Can you verify when and if the PR will be added to the 2.0 spec? We do not want to fix it as a bug in the OM validator unless it is reflective of what is actually in the spec. Thanks, Ryan  From: David Filip [ mailto:david.filip@adaptcentre.ie ] Sent: Thursday, December 17, 2015 3:01 PM To: Patrik Mazanek < pmazanek@sdl.com > Cc: XLIFF Main List < xliff@lists.oasis-open.org > Subject: Re: [xliff] <sm/> and <em/>   Thanks, Patrik, there was a discussion on this back in summer 2014.   While orphaned <sc/> and <ec/> are possible and allowed because XLIFF Agents are not in control of the native markup in the original and target format.   Now, XLIFF Agents are always in control of annotations. The <mrk> and <sm/>/<em/> behave largely analogically to <pc> and <sc/>/<ec/> except that they don't have attributes and Constraints and PRs to handle orphaned cases. It follows implicitly that orphaned <sm/> or <em/> are not allowed in a scope of any <unit>. I guess the Okapi and MSFT OM don't catch this, as there is no explicit Constraint or PR to prohibit that. I would suggest that we add such PR, as it wouldn't be really chanhing the spec materially, just adding explicit wording to what otherwise follows implicitly.   Cheers 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 Thu, Dec 17, 2015 at 1:49 PM, Patrik Mazanek < pmazanek@sdl.com > wrote: HI, I wanted to ask about <sm/> and <em/> tags. In specification it is said that the marker can be created by using <mrk> tag pair , or the pair of <sm> and <em> elements. What it doesn’t say if you can have situation where only <sm/> or <em/> is present, e.g.:   <xliff xmlns="urn:oasis:names:tc:xliff:document:2.0" xmlns:fs="urn:oasis:names:tc:xliff:fs:2.0" xmlns:slr="urn:oasis:names:tc:xliff:sizerestriction:2.0" version="2.0" xml:space="preserve" srcLang="en-GB" trgLang="fr-FR">     <file id="f1" original="myfile">         <unit id="1">             <segment id="id1" >                <source>Example of an sm with  <sm id="2" type="term"/> term</source>             </segment>         </unit>     </file> </xliff>   It seems both Okapi validator and MS XLIFF OM validate the example above as valid file. If this is indeed correct I believe we should enhance the specification and make sure this bit is explained a bit better.   Regards   Patrik Mazanek   l   Product Owner – Translation productivity l   SDL   l   Language Technologies Division   l   (T) +49 (0)1520 9098850 l   (F)   +49 711 780 4197  


  • 6.  RE: [xliff]

    Posted 02-23-2016 18:01




    Thanks David, that gives me the clarity I need to make a decision to not allow orphan annotations in the MS XLIFF OM. If someone on this thread disagrees with
    this, please speak up.
     
    Thanks,
    Ryan
     
    From: David Filip [mailto:david.filip@adaptcentre.ie]

    Sent: Tuesday, February 23, 2016 9:57 AM
    To: Ryan King <ryanki@microsoft.com>
    Cc: XLIFF Main List <xliff@lists.oasis-open.org>
    Subject: Re: [xliff] <sm/> and <em/>
     

    Thanks, Ryan, IMHO that's correct.

    Only a pair of <sm> <em> can form an annotation span as per the highlighted 2.0 section.


     


    I am open to discussing how to make this clearer in 2.1.


     


    Cheers


    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 Tue, Feb 23, 2016 at 5:43 PM, Ryan King < ryanki@microsoft.com > wrote:



    Thanks, David, I understand (and agree with) the rigidity of the 2.0 standard. So, if I understand your intent below,
    is it fair to say that most likely because of this section:
    4.7.3.2 Splitting Annotations
    Orphan <sm> and <em> are not allowed because:
    1)      
    As stated in that section: Annotations can overlap spanning inline codes or other annotations. They also can be split by segmentation. Because of this, **a single** annotation
    span can be represented using **a pair** of
    <sm> and
    <em> elements instead of a single
    <mrk> element.
    2)      
    It is, therefore, implicitly understood that orphaning is not allowed because of the asterisks added above and the fact that there is no further mention of how to deal with orphaned
    tags.
     
    Is that correct?
     
    Thanks,
    Ryan
     
    From: David Filip [mailto: david.filip@adaptcentre.ie ]

    Sent: Monday, February 22, 2016 6:03 PM
    To: Ryan King < ryanki@microsoft.com >
    Cc: XLIFF Main List < xliff@lists.oasis-open.org >
    Subject: RE: [xliff] <sm/> and <em/>


     
    Hi Ryan, apologies, I haven't answered yet.
    We discussed this in the last TC and Fredrik took the action item to answer with a spec reference.

    In short, the spec says that annotations are either mrk or pairs of sm / em.
    Fredrik will provide the reference.
    isolated doesn't exist, by design, on sm / em, so really there is no mechanism to make orphaned annotations, and hence no need for an explicit Constraint prohibiting them.
    Finally, I want to clarify - and I said the same in the last meeting (not sure if the minutes are out yet) - that it is impossible to change XLIFF 2.0.
    The OASIS process has produced XLIFF 2.0, which is now immutable, "set in stone" if you wish. This is true for any OASIS Standard and in fact for any numbered draft of any OASIS standard work product, starting with cs01. Anyways, OASIS Standard is the last
    state of the OASIS state machine; editorial fixes can be pushed through Errata. But to amend anything you need to "deprecate" the old standard with producing a new standard that replaces and supersedes the older version..

    We agreed not to spend time and effort on producing Errata.
    Instead, where core seems unclear or open to more than 1 interpretation, we are free (and have agreed) to add more clarity when restating the core in 2.1.

    IMHO, we don't need an explicit Constraint saying that orphaned sm / em are invalid.

    But at the same time, if the TC agrees that having such an explicit Constraint brings more clarity, I think there is no issue with having it in 2.1. It doesn't constitute a material or logical change compared to what 2.0 core states, IMHO and AFAIK.

    Personally, I believe that it would be enough to add a Note and invalid test suite files with orphaned sm and em. BTW, we are free to maintain / amend the 2.0 test suite, as the test suite is not a formal part of the multi-part work product; merely an implementation
    aid that the TC promised to provide..
    I hope this helps
    Cheers
    dF

    On Feb 23, 2016 02:15, "Ryan King" < ryanki@microsoft.com > wrote:



    Hi David, apologies if you already answered and I missed it. Can you clarify my question below?
     
    Thanks,
    Ryan
     


    From:
    xliff@lists.oasis-open.org [mailto: xliff@lists.oasis-open.org ]
    On Behalf Of Ryan King
    Sent: Tuesday, February 2, 2016 11:40 AM
    To: ' xliff@lists.oasis-open.org ' < xliff@lists.oasis-open.org >
    Subject: [xliff] <sm/> and <em/>


     




    Hi David, Patrik logged a bug for this against the MS XLIFF 2.0 OM on GitHub. Can you verify when and if the PR will be added to the 2.0 spec? We do
    not want to fix it as a bug in the OM validator unless it is reflective of what is actually in the spec.
    Thanks,
    Ryan 
    From: David Filip [ mailto:david.filip@adaptcentre.ie ]

    Sent: Thursday, December 17, 2015 3:01 PM
    To: Patrik Mazanek < pmazanek@sdl.com >
    Cc: XLIFF Main List < xliff@lists.oasis-open.org >
    Subject: Re: [xliff] <sm/> and <em/>
     
    Thanks, Patrik, there was a discussion on this back in summer 2014.
     
    While orphaned <sc/> and <ec/> are possible and allowed because XLIFF Agents are not in control of the native markup in the original and target format.
     
    Now, XLIFF Agents are always in control of annotations. The <mrk> and <sm/>/<em/> behave largely analogically to <pc> and <sc/>/<ec/> except that they don't have attributes and
    Constraints and PRs to handle orphaned cases.
    It follows implicitly that orphaned <sm/> or <em/> are not allowed in a scope of any <unit>.
    I guess the Okapi and MSFT OM don't catch this, as there is no explicit Constraint or PR to prohibit that.
    I would suggest that we add such PR, as it wouldn't be really chanhing the spec materially, just adding explicit wording to what otherwise follows implicitly.
     
    Cheers
    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 Thu, Dec 17, 2015 at 1:49 PM, Patrik Mazanek < pmazanek@sdl.com > wrote:
    HI,
    I wanted to ask about <sm/> and <em/> tags. In specification it is said that the marker can be created by using <mrk> tag pair , or the pair of <sm> and <em> elements. What it doesn’t
    say if you can have situation where only <sm/> or <em/> is present, e.g.:
     
    <xliff xmlns="urn:oasis:names:tc:xliff:document:2.0" xmlns:fs="urn:oasis:names:tc:xliff:fs:2.0" xmlns:slr="urn:oasis:names:tc:xliff:sizerestriction:2.0" version="2.0" xml:space="preserve"
    srcLang="en-GB" trgLang="fr-FR">
        <file id="f1" original="myfile">
            <unit id="1">
                <segment id="id1" >
                   <source>Example of an sm with  <sm id="2" type="term"/> term</source>
                </segment>
            </unit>
        </file>
    </xliff>
     
    It seems both Okapi validator and MS XLIFF OM validate the example above as valid file. If this is indeed correct I believe we should enhance the specification and make sure this
    bit is explained a bit better.
     
    Regards
     
    Patrik Mazanek  
    l  
    Product Owner – Translation productivity
    l
      SDL
      l  
    Language Technologies Division  
    l  
    (T)
    +49 (0)1520 9098850
    l  
    (F)   +49 711 780 4197




     










     







  • 7.  RE: [xliff]

    Posted 02-23-2016 18:05
    +1 on that interpretation, as we discussed.   I’ll update the Okapi library verification to catch orphan sm and em. (Currently they don’t yield any error).   -ys     From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Ryan King Sent: Tuesday, February 23, 2016 1:43 PM To: David Filip <david.filip@adaptcentre.ie> Cc: XLIFF Main List <xliff@lists.oasis-open.org> Subject: RE: [xliff] <sm/> and <em/>   Thanks, David, I understand (and agree with) the rigidity of the 2.0 standard. So, if I understand your intent below, is it fair to say that most likely because of this section: 4.7.3.2 Splitting Annotations Orphan <sm> and <em> are not allowed because: 1)        As stated in that section: Annotations can overlap spanning inline codes or other annotations. They also can be split by segmentation. Because of this, **a single** annotation span can be represented using **a pair** of <sm> and <em> elements instead of a single <mrk> element. 2)        It is, therefore, implicitly understood that orphaning is not allowed because of the asterisks added above and the fact that there is no further mention of how to deal with orphaned tags.   Is that correct?   Thanks, Ryan   From: David Filip [ mailto:david.filip@adaptcentre.ie ] Sent: Monday, February 22, 2016 6:03 PM To: Ryan King < ryanki@microsoft.com > Cc: XLIFF Main List < xliff@lists.oasis-open.org > Subject: RE: [xliff] <sm/> and <em/>   Hi Ryan, apologies, I haven't answered yet. We discussed this in the last TC and Fredrik took the action item to answer with a spec reference. In short, the spec says that annotations are either mrk or pairs of sm / em. Fredrik will provide the reference. isolated doesn't exist, by design, on sm / em, so really there is no mechanism to make orphaned annotations, and hence no need for an explicit Constraint prohibiting them. Finally, I want to clarify - and I said the same in the last meeting (not sure if the minutes are out yet) - that it is impossible to change XLIFF 2.0. The OASIS process has produced XLIFF 2.0, which is now immutable, "set in stone" if you wish. This is true for any OASIS Standard and in fact for any numbered draft of any OASIS standard work product, starting with cs01. Anyways, OASIS Standard is the last state of the OASIS state machine; editorial fixes can be pushed through Errata. But to amend anything you need to "deprecate" the old standard with producing a new standard that replaces and supersedes the older version.. We agreed not to spend time and effort on producing Errata. Instead, where core seems unclear or open to more than 1 interpretation, we are free (and have agreed) to add more clarity when restating the core in 2.1. IMHO, we don't need an explicit Constraint saying that orphaned sm / em are invalid. But at the same time, if the TC agrees that having such an explicit Constraint brings more clarity, I think there is no issue with having it in 2.1. It doesn't constitute a material or logical change compared to what 2.0 core states, IMHO and AFAIK. Personally, I believe that it would be enough to add a Note and invalid test suite files with orphaned sm and em. BTW, we are free to maintain / amend the 2.0 test suite, as the test suite is not a formal part of the multi-part work product; merely an implementation aid that the TC promised to provide.. I hope this helps Cheers dF On Feb 23, 2016 02:15, "Ryan King" < ryanki@microsoft.com > wrote: Hi David, apologies if you already answered and I missed it. Can you clarify my question below?   Thanks, Ryan   From: xliff@lists.oasis-open.org [mailto: xliff@lists.oasis-open.org ] On Behalf Of Ryan King Sent: Tuesday, February 2, 2016 11:40 AM To: ' xliff@lists.oasis-open.org ' < xliff@lists.oasis-open.org > Subject: [xliff] <sm/> and <em/>   Hi David, Patrik logged a bug for this against the MS XLIFF 2.0 OM on GitHub. Can you verify when and if the PR will be added to the 2.0 spec? We do not want to fix it as a bug in the OM validator unless it is reflective of what is actually in the spec. Thanks, Ryan  From: David Filip [ mailto:david.filip@adaptcentre.ie ] Sent: Thursday, December 17, 2015 3:01 PM To: Patrik Mazanek < pmazanek@sdl.com > Cc: XLIFF Main List < xliff@lists.oasis-open.org > Subject: Re: [xliff] <sm/> and <em/>   Thanks, Patrik, there was a discussion on this back in summer 2014.   While orphaned <sc/> and <ec/> are possible and allowed because XLIFF Agents are not in control of the native markup in the original and target format.   Now, XLIFF Agents are always in control of annotations. The <mrk> and <sm/>/<em/> behave largely analogically to <pc> and <sc/>/<ec/> except that they don't have attributes and Constraints and PRs to handle orphaned cases. It follows implicitly that orphaned <sm/> or <em/> are not allowed in a scope of any <unit>. I guess the Okapi and MSFT OM don't catch this, as there is no explicit Constraint or PR to prohibit that. I would suggest that we add such PR, as it wouldn't be really chanhing the spec materially, just adding explicit wording to what otherwise follows implicitly.   Cheers 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 Thu, Dec 17, 2015 at 1:49 PM, Patrik Mazanek < pmazanek@sdl.com > wrote: HI, I wanted to ask about <sm/> and <em/> tags. In specification it is said that the marker can be created by using <mrk> tag pair , or the pair of <sm> and <em> elements. What it doesn’t say if you can have situation where only <sm/> or <em/> is present, e.g.:   <xliff xmlns="urn:oasis:names:tc:xliff:document:2.0" xmlns:fs="urn:oasis:names:tc:xliff:fs:2.0" xmlns:slr="urn:oasis:names:tc:xliff:sizerestriction:2.0" version="2.0" xml:space="preserve" srcLang="en-GB" trgLang="fr-FR">     <file id="f1" original="myfile">         <unit id="1">             <segment id="id1" >                <source>Example of an sm with  <sm id="2" type="term"/> term</source>             </segment>         </unit>     </file> </xliff>   It seems both Okapi validator and MS XLIFF OM validate the example above as valid file. If this is indeed correct I believe we should enhance the specification and make sure this bit is explained a bit better.   Regards   Patrik Mazanek   l   Product Owner – Translation productivity l   SDL   l   Language Technologies Division   l   (T) +49 (0)1520 9098850 l   (F)   +49 711 780 4197