OASIS XML Localisation Interchange File Format (XLIFF) TC

  • 1.  Reference implementations for XLIFF 2.0

    Posted 06-29-2013 00:08
    I would like to re-start the discussion of reference implementation requirements for XLIFF 2.0. This topic was discussed at the f2f in London, but I don’t believe we reached any final decision/conclusion.   As I recall, there was some debate about the official requirements for reference implementation – it appeared unclear whether we must have reference implementation for everything in the 2.0 standard (each and every module). While that approach would provide optimal assurance and confidence in the standard, it would be difficult to find commitment for extensive implementation work from likely implementers in the near future.   We discussed the various options, which included (to the best of my memory):   1.       Only publish modules in 2.0 that have been proven and implemented; anything not implemented would be cut 2.       Ask 3 implementers to supply simple proofs of their implementation of XLIFF 2.0 (loosely defined) – i.e. meet the minimum requirements for OASIS 3.       Wait until all modules have been provable implemented and delay XLIFF 2.0 publication until such time   There may be other options – please share if there are. However, of the above, option #2 seems the most pragmatic and realistic to me, given the desire to finalize and publish XLIFF 2.0 this year. Option 1 risks publishing a piece-meal standard, while Option 3 risks delaying XLIFF 2.0 significantly. For option 2, there is a risk that some implementation detail in XLIFF 2.0 will not be caught prior to publication, but I believe that is better addressed in a future XLIFF 2.1 version.   Do we have confirmation of the OASIS requirements for reference implementations, with specific detail? If so, can we take a decision on the approach to achieving the appropriate level of reference implementation to meet the timeline that Bryan has created?   Thanks, Kevin.


  • 2.  Re: [xliff] Reference implementations for XLIFF 2.0

    Posted 07-01-2013 15:42
    I think option 2 would work well especially
    if there is one in the three that is "open" implementation.




    From:      
      "Kevin O'Donnell"
    <kevinod@microsoft.com>
    To:      
      "xliff@lists.oasis-open.org"
    <xliff@lists.oasis-open.org>
    Date:      
      06/28/2013 08:09 PM
    Subject:    
        [xliff] Reference
    implementations for XLIFF 2.0
    Sent by:    
        <xliff@lists.oasis-open.org>




    I would like to re-start the discussion
    of reference implementation requirements for XLIFF 2.0. This topic was
    discussed at the f2f in London, but I don’t believe we reached any final
    decision/conclusion.
     
    As I recall, there was some debate about
    the official requirements for reference implementation – it appeared unclear
    whether we must have reference implementation for everything in
    the 2.0 standard (each and every module). While that approach would provide
    optimal assurance and confidence in the standard, it would be difficult
    to find commitment for extensive implementation work from likely implementers
    in the near future.
     
    We discussed the various options, which
    included (to the best of my memory):
     
    1.      Only publish modules
    in 2.0 that have been proven and implemented; anything not implemented
    would be cut
    2.      Ask 3 implementers
    to supply simple proofs of their implementation of XLIFF 2.0 (loosely defined)
    – i.e. meet the minimum requirements for OASIS
    3.      Wait until all modules
    have been provable implemented and delay XLIFF 2.0 publication until such
    time
     
    There may be other options – please share
    if there are. However, of the above, option #2 seems the most pragmatic
    and realistic to me, given the desire to finalize and publish XLIFF 2.0
    this year. Option 1 risks publishing a piece-meal standard, while Option
    3 risks delaying XLIFF 2.0 significantly. For option 2, there is a risk
    that some implementation detail in XLIFF 2.0 will not be caught prior to
    publication, but I believe that is better addressed in a future XLIFF 2.1
    version.
     
    Do we have confirmation of the OASIS requirements
    for reference implementations, with specific detail? If so, can we take
    a decision on the approach to achieving the appropriate level of reference
    implementation to meet the timeline that Bryan has created?
     
    Thanks,
    Kevin.




  • 3.  RE: [xliff] Reference implementations for XLIFF 2.0

    Posted 07-01-2013 16:54




    Kevin,
     
    Thanks for outlining this in such a very clear way. I agree with you and Helena that option 2 seems best.
     
    And as for OASIS requirements, the most definitive policy definition I could find is under “Definitions,” item (ar), “Statements of Use,”  in the TC Policy
    Guidelines ( https://www.oasis-open.org/policies-guidelines/tc-process#definitions ).
     
    (Chet, if please let us know if there’s another guideline we should be looking at regarding “Statements of Use.”)
     
    From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org]
    On Behalf Of Helena S Chapman
    Sent: Monday, July 01, 2013 8:42 AM
    To: Kevin O'Donnell
    Cc: xliff@lists.oasis-open.org
    Subject: Re: [xliff] Reference implementations for XLIFF 2.0
     
    I think option 2 would work well especially if there is one in the three that is "open" implementation.





    From:         "Kevin O'Donnell" < kevinod@microsoft.com >

    To:         " xliff@lists.oasis-open.org " < xliff@lists.oasis-open.org >

    Date:         06/28/2013 08:09 PM

    Subject:         [xliff] Reference implementations for XLIFF 2.0

    Sent by:         < xliff@lists.oasis-open.org >







    I would like to re-start the discussion of reference implementation requirements for XLIFF 2.0. This topic was discussed at the f2f in London, but I don’t believe we reached any final decision/conclusion.

     
    As I recall, there was some debate about the official requirements for reference implementation – it appeared unclear whether we must have reference implementation for
    everything in the 2.0 standard (each and every module). While that approach would provide optimal assurance and confidence in the standard, it would be difficult to find commitment for extensive implementation work from likely implementers in the near
    future.
     
    We discussed the various options, which included (to the best of my memory):

     
    1.      Only publish modules in 2.0 that have been proven and implemented; anything not implemented would be cut

    2.      Ask 3 implementers to supply simple proofs of their implementation of XLIFF 2.0 (loosely defined) – i.e. meet the minimum requirements for OASIS

    3.      Wait until all modules have been provable implemented and delay XLIFF 2.0 publication until such time

     
    There may be other options – please share if there are. However, of the above, option #2 seems the most pragmatic and realistic to me, given the desire to finalize and publish XLIFF 2.0 this
    year. Option 1 risks publishing a piece-meal standard, while Option 3 risks delaying XLIFF 2.0 significantly. For option 2, there is a risk that some implementation detail in XLIFF 2.0 will not be caught prior to publication, but I believe that is better addressed
    in a future XLIFF 2.1 version.
     
    Do we have confirmation of the OASIS requirements for reference implementations, with specific detail? If so, can we take a decision on the approach to achieving the appropriate level of reference
    implementation to meet the timeline that Bryan has created?
     
    Thanks,
    Kevin.







  • 4.  Re: [xliff] Reference implementations for XLIFF 2.0

    Posted 07-01-2013 19:34
    Hi Bryan,  You are correct - that is the definitive statement. Note in particular...  - The typical language used for a Statement of Use is similar to "<company>has successfully implemented and used the <title of the Committee Specification, version # and stage number (e.g. Committee Specification 02)>" in accordance with the conformance clauses specified in <section of the CS>.  The implementation included interoperation with other independent." -- Your providers are free to add as much detail or color to this as they wish but this gives the minimum required information.  - The SoUs are not required to cover every part of your CS - but they do need to say, via the reference to the conformance clases, what they cover. So, for example, "... in accordance with the conformance clauses in section 6.2.2 and 6.2.3.." or something similar to that. It is up to you all to decide if you feel satisfied that you have sufficient coverage but if it appears that there are significant areas where implementation hasn't been demonstrated, that could lead to negative comments during the public review and / or negative votes at the OS stage.  - You need a minimum of 3 SoUs and at least one must come from an OASIS Organizational Member. Any SoUs coming from an organizational member must be either submitted by the primary or confirmed by the primary.  Let me know if you have other questions.  Best,  /chet     On Mon, Jul 1, 2013 at 12:53 PM, Schnabel, Bryan S < bryan.s.schnabel@tektronix.com > wrote: Kevin,   Thanks for outlining this in such a very clear way. I agree with you and Helena that option 2 seems best.   And as for OASIS requirements, the most definitive policy definition I could find is under “Definitions,” item (ar), “Statements of Use,”  in the TC Policy Guidelines ( https://www.oasis-open.org/policies-guidelines/tc-process#definitions ).   (Chet, if please let us know if there’s another guideline we should be looking at regarding “Statements of Use.”)   From: xliff@lists.oasis-open.org [mailto: xliff@lists.oasis-open.org ] On Behalf Of Helena S Chapman Sent: Monday, July 01, 2013 8:42 AM To: Kevin O'Donnell Cc: xliff@lists.oasis-open.org Subject: Re: [xliff] Reference implementations for XLIFF 2.0   I think option 2 would work well especially if there is one in the three that is "open" implementation. From:         "Kevin O'Donnell" < kevinod@microsoft.com > To:         " xliff@lists.oasis-open.org " < xliff@lists.oasis-open.org > Date:         06/28/2013 08:09 PM Subject:         [xliff] Reference implementations for XLIFF 2.0 Sent by:         < xliff@lists.oasis-open.org > I would like to re-start the discussion of reference implementation requirements for XLIFF 2.0. This topic was discussed at the f2f in London, but I don’t believe we reached any final decision/conclusion.   As I recall, there was some debate about the official requirements for reference implementation – it appeared unclear whether we must have reference implementation for everything in the 2.0 standard (each and every module). While that approach would provide optimal assurance and confidence in the standard, it would be difficult to find commitment for extensive implementation work from likely implementers in the near future.   We discussed the various options, which included (to the best of my memory):   1.      Only publish modules in 2.0 that have been proven and implemented; anything not implemented would be cut 2.      Ask 3 implementers to supply simple proofs of their implementation of XLIFF 2.0 (loosely defined) – i.e. meet the minimum requirements for OASIS 3.      Wait until all modules have been provable implemented and delay XLIFF 2.0 publication until such time   There may be other options – please share if there are. However, of the above, option #2 seems the most pragmatic and realistic to me, given the desire to finalize and publish XLIFF 2.0 this year. Option 1 risks publishing a piece-meal standard, while Option 3 risks delaying XLIFF 2.0 significantly. For option 2, there is a risk that some implementation detail in XLIFF 2.0 will not be caught prior to publication, but I believe that is better addressed in a future XLIFF 2.1 version.   Do we have confirmation of the OASIS requirements for reference implementations, with specific detail? If so, can we take a decision on the approach to achieving the appropriate level of reference implementation to meet the timeline that Bryan has created?   Thanks, Kevin. -- /chet  ---------------- Chet Ensign Director of Standards Development and TC Administration  OASIS: Advancing open standards for the information society http://www.oasis-open.org Primary: +1 973-996-2298 Mobile: +1 201-341-1393  Check your work using the Support Request Submission Checklist at  http://www.oasis-open.org/committees/download.php/47248/tc-admin-submission-checklist.html   TC Administration information and support is available at http://www.oasis-open.org/resources/tcadmin Follow OASIS on: LinkedIn:     http://linkd.in/OASISopen Twitter:         http://twitter.com/OASISopen Facebook:   http://facebook.com/oasis.open


  • 5.  RE: [xliff] Reference implementations for XLIFF 2.0

    Posted 07-01-2013 19:36
    Thanks Chet. That helps a lot. We will let you know if we have further questions.   - Bryan   From: Chet Ensign [mailto:chet.ensign@oasis-open.org] Sent: Monday, July 01, 2013 12:34 PM To: Schnabel, Bryan S Cc: Helena S Chapman; Kevin O'Donnell; xliff@lists.oasis-open.org Subject: Re: [xliff] Reference implementations for XLIFF 2.0   Hi Bryan,    You are correct - that is the definitive statement. Note in particular...    - The typical language used for a Statement of Use is similar to "<company>has successfully implemented and used the <title of the Committee Specification, version # and stage number (e.g. Committee Specification 02)>" in accordance with the conformance clauses specified in <section of the CS>.  The implementation included interoperation with other independent." -- Your providers are free to add as much detail or color to this as they wish but this gives the minimum required information.    - The SoUs are not required to cover every part of your CS - but they do need to say, via the reference to the conformance clases, what they cover. So, for example, "... in accordance with the conformance clauses in section 6.2.2 and 6.2.3.." or something similar to that. It is up to you all to decide if you feel satisfied that you have sufficient coverage but if it appears that there are significant areas where implementation hasn't been demonstrated, that could lead to negative comments during the public review and / or negative votes at the OS stage.    - You need a minimum of 3 SoUs and at least one must come from an OASIS Organizational Member. Any SoUs coming from an organizational member must be either submitted by the primary or confirmed by the primary.    Let me know if you have other questions.    Best,    /chet             On Mon, Jul 1, 2013 at 12:53 PM, Schnabel, Bryan S < bryan.s.schnabel@tektronix.com > wrote: Kevin,   Thanks for outlining this in such a very clear way. I agree with you and Helena that option 2 seems best.   And as for OASIS requirements, the most definitive policy definition I could find is under “Definitions,” item (ar), “Statements of Use,”  in the TC Policy Guidelines ( https://www.oasis-open.org/policies-guidelines/tc-process#definitions ).   (Chet, if please let us know if there’s another guideline we should be looking at regarding “Statements of Use.”)   From: xliff@lists.oasis-open.org [mailto: xliff@lists.oasis-open.org ] On Behalf Of Helena S Chapman Sent: Monday, July 01, 2013 8:42 AM To: Kevin O'Donnell Cc: xliff@lists.oasis-open.org Subject: Re: [xliff] Reference implementations for XLIFF 2.0   I think option 2 would work well especially if there is one in the three that is "open" implementation. From:         "Kevin O'Donnell" < kevinod@microsoft.com > To:         " xliff@lists.oasis-open.org " < xliff@lists.oasis-open.org > Date:         06/28/2013 08:09 PM Subject:         [xliff] Reference implementations for XLIFF 2.0 Sent by:         < xliff@lists.oasis-open.org > I would like to re-start the discussion of reference implementation requirements for XLIFF 2.0. This topic was discussed at the f2f in London, but I don’t believe we reached any final decision/conclusion.   As I recall, there was some debate about the official requirements for reference implementation – it appeared unclear whether we must have reference implementation for everything in the 2.0 standard (each and every module). While that approach would provide optimal assurance and confidence in the standard, it would be difficult to find commitment for extensive implementation work from likely implementers in the near future.   We discussed the various options, which included (to the best of my memory):   1.      Only publish modules in 2.0 that have been proven and implemented; anything not implemented would be cut 2.      Ask 3 implementers to supply simple proofs of their implementation of XLIFF 2.0 (loosely defined) – i.e. meet the minimum requirements for OASIS 3.      Wait until all modules have been provable implemented and delay XLIFF 2.0 publication until such time   There may be other options – please share if there are. However, of the above, option #2 seems the most pragmatic and realistic to me, given the desire to finalize and publish XLIFF 2.0 this year. Option 1 risks publishing a piece-meal standard, while Option 3 risks delaying XLIFF 2.0 significantly. For option 2, there is a risk that some implementation detail in XLIFF 2.0 will not be caught prior to publication, but I believe that is better addressed in a future XLIFF 2.1 version.   Do we have confirmation of the OASIS requirements for reference implementations, with specific detail? If so, can we take a decision on the approach to achieving the appropriate level of reference implementation to meet the timeline that Bryan has created?   Thanks, Kevin.   -- /chet  ---------------- Chet Ensign Director of Standards Development and TC Administration  OASIS: Advancing open standards for the information society http://www.oasis-open.org Primary: +1 973-996-2298 Mobile: +1 201-341-1393    Check your work using the Support Request Submission Checklist at  http://www.oasis-open.org/committees/download.php/47248/tc-admin-submission-checklist.html   TC Administration information and support is available at http://www.oasis-open.org/resources/tcadmin Follow OASIS on: LinkedIn:     http://linkd.in/OASISopen Twitter:         http://twitter.com/OASISopen Facebook:   http://facebook.com/oasis.open


  • 6.  Re: [xliff] Reference implementations for XLIFF 2.0

    Posted 07-01-2013 20:37
    Thanks, Chet, this is very helpful dF Dr. David Filip ======================= LRC CNGL LT-Web CSIS University of Limerick, Ireland telephone: +353-6120-2781 cellphone: +353-86-0222-158 facsimile: +353-6120-2734 mailto: david.filip@ul.ie On Mon, Jul 1, 2013 at 8:33 PM, Chet Ensign < chet.ensign@oasis-open.org > wrote: Hi Bryan,  You are correct - that is the definitive statement. Note in particular...  - The typical language used for a Statement of Use is similar to "<company>has successfully implemented and used the <title of the Committee Specification, version # and stage number (e.g. Committee Specification 02)>" in accordance with the conformance clauses specified in <section of the CS>.  The implementation included interoperation with other independent." -- Your providers are free to add as much detail or color to this as they wish but this gives the minimum required information.  - The SoUs are not required to cover every part of your CS - but they do need to say, via the reference to the conformance clases, what they cover. So, for example, "... in accordance with the conformance clauses in section 6.2.2 and 6.2.3.." or something similar to that. It is up to you all to decide if you feel satisfied that you have sufficient coverage but if it appears that there are significant areas where implementation hasn't been demonstrated, that could lead to negative comments during the public review and / or negative votes at the OS stage.  - You need a minimum of 3 SoUs and at least one must come from an OASIS Organizational Member. Any SoUs coming from an organizational member must be either submitted by the primary or confirmed by the primary.  Let me know if you have other questions.  Best,  /chet     On Mon, Jul 1, 2013 at 12:53 PM, Schnabel, Bryan S < bryan.s.schnabel@tektronix.com > wrote: Kevin,   Thanks for outlining this in such a very clear way. I agree with you and Helena that option 2 seems best.   And as for OASIS requirements, the most definitive policy definition I could find is under “Definitions,” item (ar), “Statements of Use,”  in the TC Policy Guidelines ( https://www.oasis-open.org/policies-guidelines/tc-process#definitions ).   (Chet, if please let us know if there’s another guideline we should be looking at regarding “Statements of Use.”)   From: xliff@lists.oasis-open.org [mailto: xliff@lists.oasis-open.org ] On Behalf Of Helena S Chapman Sent: Monday, July 01, 2013 8:42 AM To: Kevin O'Donnell Cc: xliff@lists.oasis-open.org Subject: Re: [xliff] Reference implementations for XLIFF 2.0   I think option 2 would work well especially if there is one in the three that is "open" implementation. From:         "Kevin O'Donnell" < kevinod@microsoft.com > To:         " xliff@lists.oasis-open.org " < xliff@lists.oasis-open.org > Date:         06/28/2013 08:09 PM Subject:         [xliff] Reference implementations for XLIFF 2.0 Sent by:         < xliff@lists.oasis-open.org > I would like to re-start the discussion of reference implementation requirements for XLIFF 2.0. This topic was discussed at the f2f in London, but I don’t believe we reached any final decision/conclusion.   As I recall, there was some debate about the official requirements for reference implementation – it appeared unclear whether we must have reference implementation for everything in the 2.0 standard (each and every module). While that approach would provide optimal assurance and confidence in the standard, it would be difficult to find commitment for extensive implementation work from likely implementers in the near future.   We discussed the various options, which included (to the best of my memory):   1.      Only publish modules in 2.0 that have been proven and implemented; anything not implemented would be cut 2.      Ask 3 implementers to supply simple proofs of their implementation of XLIFF 2.0 (loosely defined) – i.e. meet the minimum requirements for OASIS 3.      Wait until all modules have been provable implemented and delay XLIFF 2.0 publication until such time   There may be other options – please share if there are. However, of the above, option #2 seems the most pragmatic and realistic to me, given the desire to finalize and publish XLIFF 2.0 this year. Option 1 risks publishing a piece-meal standard, while Option 3 risks delaying XLIFF 2.0 significantly. For option 2, there is a risk that some implementation detail in XLIFF 2.0 will not be caught prior to publication, but I believe that is better addressed in a future XLIFF 2.1 version.   Do we have confirmation of the OASIS requirements for reference implementations, with specific detail? If so, can we take a decision on the approach to achieving the appropriate level of reference implementation to meet the timeline that Bryan has created?   Thanks, Kevin. -- /chet  ---------------- Chet Ensign Director of Standards Development and TC Administration  OASIS: Advancing open standards for the information society http://www.oasis-open.org Primary: +1 973-996-2298 Mobile: +1 201-341-1393   Check your work using the Support Request Submission Checklist at  http://www.oasis-open.org/committees/download.php/47248/tc-admin-submission-checklist.html   TC Administration information and support is available at http://www.oasis-open.org/resources/tcadmin Follow OASIS on: LinkedIn:     http://linkd.in/OASISopen Twitter:         http://twitter.com/OASISopen Facebook:   http://facebook.com/oasis.open


  • 7.  RE: [xliff] Reference implementations for XLIFF 2.0

    Posted 07-02-2013 13:10
    Hi Kevin, Bryan, David, all, > 1. Only publish modules in 2.0 that have been proven > and implemented; anything not implemented would be cut > 2. Ask 3 implementers to supply simple proofs of their > implementation of XLIFF 2.0 (loosely defined) – i.e. > meet the minimum requirements for OASIS > 3. Wait until all modules have been provable implemented > and delay XLIFF 2.0 publication until such time With the flurry of changes I'm seeing after this first public review I think there is a need to ensure our specification is validated by some implementations. The requirements set by OASIS are, in my opinion, rather weak: Letting the TC decide what constitutes an acceptable Statement Of Use is rather funny. It's like letting a student grad his own exam paper. I would expect to have each conformance clause met by, at least, one implementation (and it could be different implementations). Ideally I would really like to see each clause covered by, at least, two to prove/test interoperability. But one would be better than none. > ...while Option 3 risks delaying XLIFF 2.0 significantly. > For option 2, there is a risk that some implementation > detail in XLIFF 2.0 will not be caught prior to publication, > but I believe that is better addressed in a future XLIFF > 2.1 version. There is option 4: Drop the module(s) that don't met the implementation requirements. That won't delay XLIFF 2.0 at all. Instead of risking the mess of having to fix implementations details in 2.1, 2.2, etc. why not get it right when it's implementation-tested? The requirement would also include the core. But if we can't cover each conformance clause of the core by at least one implementation, we probably shouldn't be publishing 2.0 yet. Just my 2 cents. Cheers, -yves