[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Commented: (CMIS-672) Use a JSON Schema
[ http://tools.oasis-open.org/issues/browse/CMIS-672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=23436#action_23436 ]
Gregory Melahn commented on CMIS-672:
-------------------------------------
Comments from OASIS General Counsel follow marked with >>
My preference would be option 2, and include the description of Orderly in the CMIS specification itself. Otherwise we publish a specification that depends on a schema language that is described in a privately maintained web site that not even exist tomorrow, or have completely different content. Including Orderly in the specification proposal could be done in a few pages and would mean the proposal is self contained.
Orderly does depend on JSON which is itself not standard as he points out. But then again, so does the whole proposal for a new CMIS binding. Unlike Orderly, JSON is so widely adopted that I don't think this is a practical problem. To handle JSON, I have asked him if would be enough just to reference the RFC for JSON, and leave it at that ? I also invited him to our call but he never responded to that offer.
>> Should be doable, but you will have two basic choices to
>> make. One is an editorial choice between a reference by incorporation
>> only, versus bringing in an appendix. The other is whether the TC
>> wishes as a judgment call to "bring in" a nonstandardized method, and
>> to what degree. Both are part tactics and part IPR issues.
>>
>> The challenge here, of course, is that Orderly is out in the cold as
>> an unofficial proposal with no IPR assurance -- and JSON itself is an
>> unapproved draft IETF RFC note. (Not a comment on quality, here, just
>> noting the legal state of the docs.)
>>
>> 1. A reference but no substantive incorporation.
>>
>> 1a. Normative references -- where an external spec or method is
>> incorporated by *reference* as a conformance requirement of an OASIS
>> spec -- are distinctly defined in and treated by OASIS rules. When
>> it's simply referenced, not incorporated in the cut-and-paste sense,
>> the external spec is excluded from the OASIS IPR-related covenants.
>>
>> So if CMIS v.X says "use JSON here", and just provides the URL, it's
>> our understanding of the rules that you have have NOT put the TC
>> members in a position where they have automatically licensed any
>> rights they may have that read against JSON.
>>
>> 1b. However, the practical reality is that people care about
>> licensing. It's possible that TC members, analysts or users WILL
>> critique the inclusion of an unofficial, IPR-unclean method, because
>> THEIR implementation problem will have to grapple with the chain of
>> title for all of the methods employed, whether or not technically
>> "within" the OASIS deliverable.
>>
>> This has happened to us before. The WSDM TC faced a tough choice back
>> in 2003 or so about incorporating some anticipated -- but not
>> completed -- standards. Without checking, I think it was that WSDM
>> wanted to use WS-Addressing, but WSDM's specs were ready, and WSA
>> wasn't finished cooking at W3C yet.
>>
>> The way we worked it out (it was Heather Kreger and me, back in the
>> day) was that, while incorporation of an uncooked spec might not be a
>> best practice, it also was not prohibited by our rules. So, since we
>> are member-driven, we asked the TC to debate whether it was wise to do
>> so. Not "legal", just "wise." As I recall, they ended up shipping a
>> *requirement* that an abstract end-point reference be used, and a
>> *recommendation* to use WSA -- which later changed to a normative
>> requirement when WSA finalized.
>>
>> 1c. This "is it cooked" issue can be acute with government users.
>> Final approved OASIS, W3C or IETF specs clearly meet their purchasing
>> requirements to use open standards. An unapproved draft or note often
>> does not. And that's what JSON & Orderly are at the moment.
>>
>> That this is an alternative representation within CMIS might help, though.
>>
>> 2. Bringing it in from the cold.
>>
>> The alternative of submitting an appendix with Orderly might be a good
>> idea, and possibly a favor to the industry, if it can be done. But
>> how complex this gets depends on whether you view Orderly as a
>> parallel method to JSON, or itself dependent on JSON compliance. I
>> don' think it's sound for OASIS to provide an official opinion on
>> this, but it *looks* to me at first glance like Orderly DOES depend
>> formally on JSON.
>>
>> In which case the problem noted in (1b) above exists at two levels:
>> (i) Use CMIS-JSON? Requires Orderly. Is that a standard?
>> (ii) Use Orderly? Requires JSON. Is that a standard?
>>
>> 2a. On JSON? RFC 4627 is in the Informational class at IETF,
>> apparently what their process calls an "RFC Editor Contribution." As
>> such, it does come with certain disclosure obligations at IETF, though
>> considerably less than standards-track document would. And my search
>> just now of the IETF DB displayed no IPR notices against it.
>> -- So from an *IPR* point of view, there is limited comfort, but
>> no big red flags visible.
>> -- From an *approval* point of view, a conservative policymaker
>> would still be ambivalent at best.
>> Judgment call for the TC, according to me.
>>
>> 2b. On Orderly? Bringing it in as a method in an appendix would
>> require two things. First. Orderly's author would need to be happy
>> contributing it for re-use, via our public comment vehicle, under the
>> no-strings-attached terms there. Which might be fine if he wants it
>> widely reused, and if he and the TC are comfortable that it is not
>> itself infringing anything. .
>>
>> 2c. The second requirement is that Mary & the TC would need to be
>> satisfied that this falls within the TC's charter. Given what some
>> other TCs (like our Emergency TC and SAML) have done with other schema
>> (like ASN.1 and SSL) that might be easy, but it's not for me to say.
>>
> Use a JSON Schema
> ------------------
>
> Key: CMIS-672
> URL: http://tools.oasis-open.org/issues/browse/CMIS-672
> Project: OASIS Content Management Interoperability Services (CMIS) TC
> Issue Type: Improvement
> Components: Browser Binding
> Affects Versions: Browser Binding Proposal
> Environment: All
> Reporter: Gregory Melahn
> Assignee: Gregory Melahn
> Fix For: Browser Binding Proposal
>
>
> Use a JSON schema to define the Browser Binding.
> Candidates include ...
> 1. Orderly: http://orderly-json.org/
> 2. JSON Schema http://json-schema.org/
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]