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

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti message

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


Subject: Re: [cti] RFI & Motion: JSON MTI & JSON Schemas


So what you are saying is the JSON Schemas should not be released as part of the official OASIS work product, but should be released as something else?  

Clearly the specification needs to be the official item as example schemas can not be restrictive enough.

Given Chet's statement, I would motion against requiring JSON Schema to be part of the specification, but rather have us release it as an information open-source project.  

Thanks,

Bret



Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." 

On Apr 12, 2016, at 11:27, Chet Ensign <chet.ensign@oasis-open.org> wrote:

Hi folks, 

One clarification regarding the OASIS rules in this respect. This is required by https://www.oasis-open.org/policies-guidelines/tc-process#specQuality, item 7 'Computer Language Definitions.' 

If a specification contains any "normative computer language definitions" whether fragments or in whole then they must be "provided in separate plain text files," those files must be referenced from the narrative text of the specification, and should there be any disagreement between the definition found in the specification and the separate file, the definition in the separate file prevails.

This isn't something the TC can overrule. Your separate computer language file will be the normative, definitive version. 

/chet


On Tue, Apr 12, 2016 at 12:30 PM, John-Mark Gurney <jmg@newcontext.com> wrote:
Jason Keirstead wrote this message on Tue, Apr 12, 2016 at 13:21 -0300:
> I agree - but I would also propose that we do not vote on a normative spec,
> until there is an affiliated schema artifact attached, regardless of if
> that artifact is classified as informative or not.

I agree that an non-normative schema is required before final vote of
the specification..  I said exactly that in my comments when I voted
for JSON to be MTI...

But as John said, Pat's question was not about a non-normative JSON
schema, but a _normative_ JSON schema, hence my comments...

--
John-Mark

---------------------------------------------------------------------
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 

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail



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