OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [xliff] Reference implementations for XLIFF 2.0


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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]