+1. Possible takeaways: a. Calling something an "RI" is accepted, but b. Our rules or guidance should put some fences around this, like "an RI" not "the RI," so as not to chill implementation. c. There are some other probable consequences that will need some thought. Like, what if an OASIS TC is making code, as a TC, but not within a repository? What's are its IPR terms and are we happy with that as safe answer? d. And like, what do RIs really mean for conformance clauses? (I could say, "they never should refer to specific commercial products" ... but is that still the right and relevant approach?) JBC On Wed, Apr 8, 2015 at 4:45 PM, Laurent M Liscia <
laurent.liscia@oasis-open.org > wrote: I like where this conversation is going. Are you noticing how much we are stretching? We're outside our comfort zone. I like it here. Now let's try and solve our customers' problems! -- Laurent Liscia, CEO OASIS: Advancing open standards for the information society (510) 669-1261 Follow OASIS on: LinkedIn:
http://linkd.in/OASISopen Twitter:
http://twitter.com/OASISopen Facebook:
http://facebook.com/oasis.open Take a tour of OASIS at:
http://www.oasis-open.org/home/tour.php On 4/8/2015 4:37 PM, Robin Cover wrote: Briefly on this topic, with one introductory note: I was surprised at the frequency of mentions ("reference implementations") that came from three different Board members when we were talking about FOSSy proposals. I can dig up my notes and SoapHub chat logs, but it surprised me that they felt no apparent angst in using the term as a natural kind of sandbox product AND a natural kind of software for TC consideration as well. I also rather expected some question on the oasis-charter-discuss list -- from regular members or Board members -- when they saw "reference implementation" as a Contribution and as a Deliverable in the CXS Charter (call for comment). Nothing: ho-hum. A couple notes inline: On Wed, Apr 8, 2015 at 5:25 PM, Jamie Clark <
jamie.clark@oasis-open.org > wrote: Agree on all the business opportunity points. Some interesting consequences though. For CXS, well, if their charter REQUIRES that they create an "open source .. implementation" as a TC deliverable, then they MUST have access to a TC working tool that permits the TC to create Open Source work as a group. (Also, their charter sort of has broken the rule that TCs cannot specify licensing terms for specs OTHER than by IPR Mode.) Also ... beyond ARIP and CXS ... DO we allow "reference implementations" now? Nothing wrong with "example" implementations, but RIs often have been thought to mean something more normative and imperative. I think we should "allow" them (viz., the use of the term), but not without proper clarification as to what an RI is. There are various kinds of RIs, for various purposes, with varying levels of completeness (optional vs required support features), and varying kinds of roles they play. Any RI needs to clarify its scope and function, and any spec citing a RI, critically needs to make the clarifications. If we are going to embrace "open source", I think we need to adjust to the comfortable use of the term "reference implementation", but with clarity about what is NOT meant. especially in connection with conformance clauses. Some kinds of behaviors exhibited by RIs, in many cases, are no different than a (normative) collection of test cases with a harnass: implementations can be handed the tests, and they (binary) pass or fail, and there's no reason not to cite the test suite in the conformance clauses. That's what tests do: express intended specification semantics by coding a test for behavior, and noting how the (thus tested) implementation behaves. An RI can/could be more (general) but the key notions may not be that different. However: clarity IS required to indicate the role and NON-role of an RI with respect to conformance clauses so that the role is clearly bounded. PS Just today I spotted an online spec document that mapped (a) functional requirements to (b) numbered conformance clauses and then (c) to (d) tests in a test suite, and finally to tested products (agents/browsers), with results displayed in a PASS or FAIL matrix for each requirement/clause/test. If a reference implementation instantiates the same kinds of testing against sample data (in some cases, using the same test code), it's notionally very similar. Summary: though I've changed my mind a couple times, I am now persuaded that there's nothing wrong with using (allowing use) "reference implementation" so long as the specification clearly qualifies and characterizes the implementation as to any possible role (or none at all) in expressing "conformant" behaviors. Also, I think we should insist -- as I regularly see done -- that a RI not be labeled as "THE" (one, only, only approved...) reference implementation, but as "A" reference implementation. So long as the term is clearly qualified to delimit and bound authority, RI should be unobjectionable: the spec has to declare what is and is not meant. -rcc The long-time line we told our Board was that RIs by TCs are discouraged, by that name, because they imply that other developers should stand down, or measure their software by the RI. I don't think I ever have seen an RI in an OASIS charter. Not my table, this decade, but you might want to have an updated viewpoint ready, un case someone asks. Also, does having an RI as a stated deliverable mean that their spec conformance clause will say "you must be exactly the same as the RI"? And would we permit that? regards Jamie On Wed, Apr 8, 2015, Laurent M Liscia <
laurent.liscia@oasis-open.org > wrote: I like all the points you're making. AIs: 1. Talk to Dave about the mode [Chet?] 2. Talk to Mike De N about repos [Jamie/Scott/Laurent?] On 4/7/2015, Robin Cover wrote: Re: the statement from Fujitsu ( Makiko Shimamura <
maki.shimamura@jp.fujitsu.com > ) " As you know, Reference Implementations are needed to promote standards ." Granting that we have not settled on (broadcasting) a formal Staff position on the use or qualified use of the term "Reference Implementation" by TC Members in connection with their chartered work ( the CXS TC asserts so [1] ) .... 1. Perhaps we should speak with someone at Fujitsu about the "Open Repository" proposal 2. If David Snelling (Fujitsu) agrees with the unqualified assertion of Makiko Shimamura ("are needed""), maybe he could persuade Joss to change the COEL TC proposal to say "Non-Assertion" rather than "RF on RAND" so that the new TC can develop or incorporate reference implementation(s) formally into TC work, via initial incubation in an OASIS Open Repository effort - rcc [1] CXS TC members have a "Reference Implementation" as a chartered Deliverable "List of Deliverables: * Open Source Reference Implementation (2015 projected completion date)"
https://www.oasis-open.org/committees/cxs/charter.php#item-4 CXS TC is chartered under Non-Assertion Mode, so they could create an Open Repository if they want... though I think they wanted to keep their work elsewhere (the external Jahia-owned GitHub) On Tue, Apr 7, 2015, Chet Ensign <
chet.ensign@oasis-open.org > wrote: Interesting comment to the ARIP draft charter. Peter B. wrote me to ask if I think this is an appropriate change so I'll be replying to him. ---------- Forwarded message ---------- From: Makiko Shimamura <
maki.shimamura@jp.fujitsu.com > Date: Mon, Apr 6, 2015 Subject: [oasis-charter-discuss] Comments on the ARIP TC Charter To:
oasis-charter-discuss@lists.oasis-open.org Cc:
jikeitou-std-contact@ml.css.fujitsu.com , SHIMAMURA Makiko <
maki.shimamura@jp.fujitsu.com > Proposers of the ARIP TC, As you know, Reference Implementations are needed to promote standards. We would like to propose to develop Reference Implementations to share our knowledge and experience and reduce troubles caused by miscommunications. > (1)(b) Statement of Purpose > * Develop specifications, guidelines, and best practices ... Please modify the above sentence to add Reference Implementations as follows: * Develop specifications, reference implementations, guidelines, ... And, please add the following sentence: * Develop a set of sample use cases including best practices on how AR can contribute on-site working in enterprise companies as one of examples. > (1)(d) Deliverables > * a set of open specifications related to the use of AR, ... Please modify the above sentence to add Reference Implementations as follows: * a set of open specifications, and reference implementations related to ... If you have any questions, please let me know. Best Regards, Makiko Shimamura FUJITSU LIMITED
maki.shimamura@jp.fujitsu.com --------------------------------------------------------------------- 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 -- /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 -- Robin Cover OASIS, Director of Information Services Editor, Cover Pages and XML Daily Newslink Email:
robin@oasis-open.org Staff bio:
http://www.oasis-open.org/people/staff/robin-cover Cover Pages:
http://xml.coverpages.org/ Newsletter:
http://xml.coverpages.org/newsletterArchive.html Tel: +1 972-296-1783 -- Robin Cover OASIS, Director of Information Services Editor, Cover Pages and XML Daily Newslink Email:
robin@oasis-open.org Staff bio:
http://www.oasis-open.org/people/staff/robin-cover Cover Pages:
http://xml.coverpages.org/ Newsletter:
http://xml.coverpages.org/newsletterArchive.html Tel: +1 972-296-1783