OASIS XML Localisation Interchange File Format (XLIFF) TC

 View Only
  • 1.  Latest Changes: Resource Data Module

    Posted 02-26-2013 01:29
      |   view attached
    Hello All,   Please find attached the latest changes for the ResourceData module based on the feedback from TC members in email and from the TC conference calls. Changes are highlighted in yellow. Please sned any additional feedback you may have. I am planning to author the docBook files add them to the specification this  week.   Thanks, Ryan Attachment: Resource Data Module.pdf Description: Resource Data Module.pdf

    Attachment(s)

    pdf
    Resource Data Module.pdf   319 KB 1 version


  • 2.  RE: [xliff] Latest Changes: Resource Data Module

    Posted 02-26-2013 05:24
    Hi Ryan, Thanks for the updated document 9and the highlights) I had time to only glance at it but noticed one thing: The resourceDataRef attribute is a URI. Is the purpose to be able to point outside the XLIFF document as well? If not and if the use case is only to reference an id (i.e. the value will be always resourceDataRef="#someid", then I wonder if it should be a URI. I think so far all reference to element has been done using the ID directly. For example in inline code to refer to <data> etc. Maybe it's better to be consistent? just wondering. cheers, -yves From: xliff@lists.oasis-open.org [ mailto:xliff@lists.oasis-open.org ] On Behalf Of Ryan King Sent: Monday, February 25, 2013 6:28 PM To: xliff@lists.oasis-open.org Subject: [xliff] Latest Changes: Resource Data Module Hello All, Please find attached the latest changes for the ResourceData module based on the feedback from TC members in email and from the TC conference calls. Changes are highlighted in yellow. Please sned any additional feedback you may have. I am planning to author the docBook files add them to the specification this week. Thanks, Ryan


  • 3.  RE: [xliff] Latest Changes: Resource Data Module

    Posted 02-26-2013 18:04




    Thanks Yves, Are you referring to nid?
     
    nid
    Original data reference - Holds the identifier of the <data> element that contains the original data for a given inline code. Value description: An XSD NMTOKEN that must be the value of the id attribute of one of the <data> element listed
    in the same <unit> element.
     
    <unit id="1">
     <segment>
       <source>Error in '<ph id="1"
    nid="d1" />'.</source>
       <target>Erreur dans '<ph id="1"
    nid="d1" />'.</target>
     </segment>
     <originalData>
       <data
    id="d1" >{0}</data>
     </originalData> </unit>
     
    I modeled resourceDataRef on the ref attribute:
     
    ref
    Reference - Holds a reference for the associated annotation.
    Value description: A value of the XSD type anyURI. The semantics of the value depends on the type of annotation:
     
    <unit id="1">
     <segment>
        <source>You use your own namespace.</source>
        <target>Vous pouvez utiliser votre propre <mrk id="m1" type="comment"
    ref="#n1" >namespace</mrk>.</target>
       <notes>
          <note
    id="n1" appliesTo="target">Please check the translation for 'namespace'. On also can use 'espace de nom', but I think most technical manuals use the English term.</note>
       </notes>
      </segment>
    </unit>
     
    I must confess, I do not understand the difference between these two referencing mechanisms. Can you please explain them to me?
     
    Thanks,
    Ryan.
     



  • 4.  RE: [xliff] Latest Changes: Resource Data Module

    Posted 02-26-2013 18:58
    Yes, I was thinking of nid.   The difference is that the nid-like value can only refer to an expected element, while a ref-like value (a URI) could potentially refer to anything outside of the document.   In the case of ref I think it’s a URI because it’s a generic access mechanism (one can refer to external note for example).   so for the resource reference I suppose if it’s always referring to a resource inside the document, avoiding the URI is probably better.   I hope I’m making sense. -ys     From: Ryan King [mailto:ryanki@microsoft.com] Sent: Tuesday, February 26, 2013 11:03 AM To: Yves Savourel; xliff@lists.oasis-open.org Subject: RE: [xliff] Latest Changes: Resource Data Module   Thanks Yves, Are you referring to nid?   nid Original data reference - Holds the identifier of the <data> element that contains the original data for a given inline code. Value description: An XSD NMTOKEN that must be the value of the id attribute of one of the <data> element listed in the same <unit> element.   <unit id="1">  <segment>    <source>Error in '<ph id="1" nid="d1" />'.</source>    <target>Erreur dans '<ph id="1" nid="d1" />'.</target>  </segment>  <originalData>    <data id="d1" >{0}</data>  </originalData> </unit>   I modeled resourceDataRef on the ref attribute:   ref Reference - Holds a reference for the associated annotation. Value description: A value of the XSD type anyURI. The semantics of the value depends on the type of annotation:   <unit id="1">  <segment>     <source>You use your own namespace.</source>     <target>Vous pouvez utiliser votre propre <mrk id="m1" type="comment" ref="#n1" >namespace</mrk>.</target>    <notes>       <note id="n1" appliesTo="target">Please check the translation for 'namespace'. On also can use 'espace de nom', but I think most technical manuals use the English term.</note>    </notes>   </segment> </unit>   I must confess, I do not understand the difference between these two referencing mechanisms. Can you please explain them to me?   Thanks, Ryan.  


  • 5.  RE: [xliff] Latest Changes: Resource Data Module

    Posted 02-26-2013 20:58




    Thanks Yves, your explanation makes sense. It does bring up an interesting point, however. Does the reference always need to refer to a <resourceData> inside the document, or as in your example for note, could
    it conceivably refer to an external <resourceData>?
     


    From: Yves Savourel [mailto:ysavourel@enlaso.com]

    Sent: Tuesday, February 26, 2013 10:58 AM
    To: Ryan King; xliff@lists.oasis-open.org
    Subject: RE: [xliff] Latest Changes: Resource Data Module


     
    Yes, I was thinking of nid.
     
    The difference is that the nid-like value can only refer to an expected element, while a ref-like value (a URI) could potentially refer to anything outside of the document.
     
    In the case of ref I think it’s a URI because it’s a generic access mechanism (one can refer to external note for example).
     
    so for the resource reference I suppose if it’s always referring to a resource inside the document, avoiding the URI is probably better.
     
    I hope I’m making sense.
    -ys
     
     


    From: Ryan King [ mailto:ryanki@microsoft.com ]

    Sent: Tuesday, February 26, 2013 11:03 AM
    To: Yves Savourel; xliff@lists.oasis-open.org
    Subject: RE: [xliff] Latest Changes: Resource Data Module


     
    Thanks Yves, Are you referring to nid?
     
    nid
    Original data reference - Holds the identifier of the <data> element that contains the original data for a given inline code. Value description: An XSD NMTOKEN that must be the value of the id attribute of one of the <data> element listed
    in the same <unit> element.
     
    <unit id="1">
     <segment>
       <source>Error in '<ph id="1"
    nid="d1" />'.</source>
       <target>Erreur dans '<ph id="1"
    nid="d1" />'.</target>
     </segment>
     <originalData>
       <data
    id="d1" >{0}</data>
     </originalData> </unit>
     
    I modeled resourceDataRef on the ref attribute:
     
    ref
    Reference - Holds a reference for the associated annotation.
    Value description: A value of the XSD type anyURI. The semantics of the value depends on the type of annotation:
     
    <unit id="1">
     <segment>
        <source>You use your own namespace.</source>
        <target>Vous pouvez utiliser votre propre <mrk id="m1" type="comment"
    ref="#n1" >namespace</mrk>.</target>
       <notes>
          <note
    id="n1" appliesTo="target">Please check the translation for 'namespace'. On also can use 'espace de nom', but I think most technical manuals use the English term.</note>
       </notes>
      </segment>
    </unit>
     
    I must confess, I do not understand the difference between these two referencing mechanisms. Can you please explain them to me?
     
    Thanks,
    Ryan.
     



  • 6.  RE: [xliff] Latest Changes: Resource Data Module

    Posted 02-26-2013 21:42
    My guess is that it’s internal. But others may have a different view point. -ys   From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Ryan King Sent: Tuesday, February 26, 2013 1:57 PM To: Yves Savourel; xliff@lists.oasis-open.org Subject: RE: [xliff] Latest Changes: Resource Data Module   Thanks Yves, your explanation makes sense. It does bring up an interesting point, however. Does the reference always need to refer to a <resourceData> inside the document, or as in your example for note, could it conceivably refer to an external <resourceData>?   From: Yves Savourel [ mailto:ysavourel@enlaso.com ] Sent: Tuesday, February 26, 2013 10:58 AM To: Ryan King; xliff@lists.oasis-open.org Subject: RE: [xliff] Latest Changes: Resource Data Module   Yes, I was thinking of nid.   The difference is that the nid-like value can only refer to an expected element, while a ref-like value (a URI) could potentially refer to anything outside of the document.   In the case of ref I think it’s a URI because it’s a generic access mechanism (one can refer to external note for example).   so for the resource reference I suppose if it’s always referring to a resource inside the document, avoiding the URI is probably better.   I hope I’m making sense. -ys     From: Ryan King [ mailto:ryanki@microsoft.com ] Sent: Tuesday, February 26, 2013 11:03 AM To: Yves Savourel; xliff@lists.oasis-open.org Subject: RE: [xliff] Latest Changes: Resource Data Module   Thanks Yves, Are you referring to nid?   nid Original data reference - Holds the identifier of the <data> element that contains the original data for a given inline code. Value description: An XSD NMTOKEN that must be the value of the id attribute of one of the <data> element listed in the same <unit> element.   <unit id="1">  <segment>    <source>Error in '<ph id="1" nid="d1" />'.</source>    <target>Erreur dans '<ph id="1" nid="d1" />'.</target>  </segment>  <originalData>    <data id="d1" >{0}</data>  </originalData> </unit>   I modeled resourceDataRef on the ref attribute:   ref Reference - Holds a reference for the associated annotation. Value description: A value of the XSD type anyURI. The semantics of the value depends on the type of annotation:   <unit id="1">  <segment>     <source>You use your own namespace.</source>     <target>Vous pouvez utiliser votre propre <mrk id="m1" type="comment" ref="#n1" >namespace</mrk>.</target>    <notes>       <note id="n1" appliesTo="target">Please check the translation for 'namespace'. On also can use 'espace de nom', but I think most technical manuals use the English term.</note>    </notes>   </segment> </unit>   I must confess, I do not understand the difference between these two referencing mechanisms. Can you please explain them to me?   Thanks, Ryan.  


  • 7.  RE: [xliff] Latest Changes: Resource Data Module

    Posted 02-27-2013 21:27




    Thanks Yves, I will keep it internal and change this to be nid-like instead of ref-like, unless I see strong feedback to the contrary.
     


    From: Yves Savourel [mailto:ysavourel@enlaso.com]

    Sent: Tuesday, February 26, 2013 1:42 PM
    To: Ryan King; xliff@lists.oasis-open.org
    Subject: RE: [xliff] Latest Changes: Resource Data Module


     
    My guess is that it’s internal.
    But others may have a different view point.
    -ys
     


    From:
    xliff@lists.oasis-open.org [ mailto:xliff@lists.oasis-open.org ]
    On Behalf Of Ryan King
    Sent: Tuesday, February 26, 2013 1:57 PM
    To: Yves Savourel; xliff@lists.oasis-open.org
    Subject: RE: [xliff] Latest Changes: Resource Data Module


     
    Thanks Yves, your explanation makes sense. It does bring up an interesting point, however. Does the reference always need to refer to a <resourceData> inside the document, or as in your example for note, could
    it conceivably refer to an external <resourceData>?
     


    From: Yves Savourel [ mailto:ysavourel@enlaso.com ]

    Sent: Tuesday, February 26, 2013 10:58 AM
    To: Ryan King; xliff@lists.oasis-open.org
    Subject: RE: [xliff] Latest Changes: Resource Data Module


     
    Yes, I was thinking of nid.
     
    The difference is that the nid-like value can only refer to an expected element, while a ref-like value (a URI) could potentially refer to anything outside of the document.
     
    In the case of ref I think it’s a URI because it’s a generic access mechanism (one can refer to external note for example).
     
    so for the resource reference I suppose if it’s always referring to a resource inside the document, avoiding the URI is probably better.
     
    I hope I’m making sense.
    -ys
     
     


    From: Ryan King [ mailto:ryanki@microsoft.com ]

    Sent: Tuesday, February 26, 2013 11:03 AM
    To: Yves Savourel; xliff@lists.oasis-open.org
    Subject: RE: [xliff] Latest Changes: Resource Data Module


     
    Thanks Yves, Are you referring to nid?
     
    nid
    Original data reference - Holds the identifier of the <data> element that contains the original data for a given inline code. Value description: An XSD NMTOKEN that must be the value of the id attribute of one of the <data> element listed
    in the same <unit> element.
     
    <unit id="1">
     <segment>
       <source>Error in '<ph id="1"
    nid="d1" />'.</source>
       <target>Erreur dans '<ph id="1"
    nid="d1" />'.</target>
     </segment>
     <originalData>
       <data
    id="d1" >{0}</data>
     </originalData> </unit>
     
    I modeled resourceDataRef on the ref attribute:
     
    ref
    Reference - Holds a reference for the associated annotation.
    Value description: A value of the XSD type anyURI. The semantics of the value depends on the type of annotation:
     
    <unit id="1">
     <segment>
        <source>You use your own namespace.</source>
        <target>Vous pouvez utiliser votre propre <mrk id="m1" type="comment"
    ref="#n1" >namespace</mrk>.</target>
       <notes>
          <note
    id="n1" appliesTo="target">Please check the translation for 'namespace'. On also can use 'espace de nom', but I think most technical manuals use the English term.</note>
       </notes>
      </segment>
    </unit>
     
    I must confess, I do not understand the difference between these two referencing mechanisms. Can you please explain them to me?
     
    Thanks,
    Ryan.
     



  • 8.  Re: [xliff] Latest Changes: Resource Data Module

    Posted 02-26-2013 13:23
    I noticed a few inconsistencies. In the syntax diagram, it indicates that there must be 1 <source> element.  In the "Processing Requirements" section of <source>, it states that "User agents may create <source> if not already present."  Which is correct? In the syntax diagram, it indicates that there may be zero, one or more <reference> elements.  In the "Contains" section of <resourceData>, it states that it can contain "Zero or one <reference> element".  Which is correct? For <reference>, the "Processing Requirements" section states the following.  So if an agent can remove and add a <reference>, why can't the agent modify a <reference> (which could be viewed as removing and adding)? User agents may create <reference> if not already present User agents should not modify <reference> User agents may remove <reference> For the "mime-type" attribute, how does an agent know how to locate the information which may need to be changed?  In your examples, there is a mime-type of "text/xml", and it mentions about having to resize a control based on the translated text.  But there may be lots of XML formats which all have resizing information defined differently.  How is an agent supposed to know which formats they need to support? David Corporate Globalization Tool Development EMail:  waltersd@us.ibm.com           Phone: (507) 253-7278,   T/L:553-7278,   Fax: (507) 253-1721 Ryan King ---02/25/2013 07:30:59 PM---Hello All, Please find attached the latest changes for the ResourceData module based on the feedback From: Ryan King <ryanki@microsoft.com> To: "xliff@lists.oasis-open.org" <xliff@lists.oasis-open.org>, Date: 02/25/2013 07:30 PM Subject: [xliff] Latest Changes: Resource Data Module Sent by: <xliff@lists.oasis-open.org> Hello All,   Please find attached the latest changes for the ResourceData module based on the feedback from TC members in email and from the TC conference calls. Changes are highlighted in yellow. Please sned any additional feedback you may have. I am planning to author the docBook files add them to the specification this  week.   Thanks, Ryan[attachment "Resource Data Module.pdf" deleted by David Walters/Rochester/IBM] --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php  


  • 9.  RE: [xliff] Latest Changes: Resource Data Module

    Posted 02-26-2013 20:34
      |   view attached
    Thanks David for the feedback. I have updated the attached pdf (highlighted in green) based on the below items.   #1 – Since removing <source> depends on whether the context attribute is set to yes, probably the creation of <source> should depend on this as well. So it should be zero or one <source> and the PR on the creation of <source> should be conditional. The same would be true for <target>. #2 – zero, one or more. #3 – I think of <reference> as a second “source” for the translator in a different language, which is for reference only, and therefore, not required for translation, so it could be created or removed depending on use case, and like a contextual <source> element, it shouldn’t be modified. #4 – We’ve discussed this on other threads. Since the XLIFF standard cannot possibly understand external XML (or other resource) formats, the most we can expect is for a user agent to do something with it based on the mime-type, e.g. for text/xml, display it in an XML viewer or editor. Beyond that, implementers would need to define a custom attribute to determine how to handle it. See my example (xtr:editor) in the attached mail. It was decided in a subsequent TC conference call to make resourceDataID part of the module, now called resourceDataRef, but the attribute for handling the resource needs to remain custom.   Thanks, Ryan       From: David Walters [mailto:waltersd@us.ibm.com] Sent: Tuesday, February 26, 2013 5:21 AM To: Ryan King Cc: xliff@lists.oasis-open.org Subject: Re: [xliff] Latest Changes: Resource Data Module   I noticed a few inconsistencies. In the syntax diagram, it indicates that there must be 1 <source> element.  In the "Processing Requirements" section of <source>, it states that "User agents may create <source> if not already present."  Which is correct? In the syntax diagram, it indicates that there may be zero, one or more <reference> elements.  In the "Contains" section of <resourceData>, it states that it can contain "Zero or one <reference> element".  Which is correct? For <reference>, the "Processing Requirements" section states the following.  So if an agent can remove and add a <reference>, why can't the agent modify a <reference> (which could be viewed as removing and adding)? User agents may create <reference> if not already present User agents should not modify <reference> User agents may remove <reference> For the "mime-type" attribute, how does an agent know how to locate the information which may need to be changed?  In your examples, there is a mime-type of "text/xml", and it mentions about having to resize a control based on the translated text.  But there may be lots of XML formats which all have resizing information defined differently.  How is an agent supposed to know which formats they need to support? David Corporate Globalization Tool Development EMail:   waltersd@us.ibm.com           Phone: (507) 253-7278,   T/L:553-7278,   Fax: (507) 253-1721 Ryan King ---02/25/2013 07:30:59 PM---Hello All, Please find attached the latest changes for the ResourceData module based on the feedback From: Ryan King < ryanki@microsoft.com > To: " xliff@lists.oasis-open.org " < xliff@lists.oasis-open.org >, Date: 02/25/2013 07:30 PM Subject: [xliff] Latest Changes: Resource Data Module Sent by: < xliff@lists.oasis-open.org > Hello All,   Please find attached the latest changes for the ResourceData module based on the feedback from TC members in email and from the TC conference calls. Changes are highlighted in yellow. Please sned any additional feedback you may have. I am planning to author the docBook files add them to the specification this  week.   Thanks, Ryan[attachment "Resource Data Module.pdf" deleted by David Walters/Rochester/IBM] --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php   ---  Begin Message  --- From : Ryan King <ryanki@microsoft.com> To : Yves Savourel <ysavourel@enlaso.com>, "xliff@lists.oasis-open.org" <xliff@lists.oasis-open.org> Date : Thu, 31 Jan 2013 20:03:24 +0000



    More inline preface with [ryanki2] :)
     

    Attachment(s)

    pdf
    Resource Data Module.pdf   319 KB 1 version