[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Addendum on NOT-normative schema formalisms [ Re: [cti] RFI & Motion: JSON MTI & JSON Schemas
Drive-by comment, for what it's worth:I understood some of the participants to say they wanted schemas declared NOT-normative content in the Work Product [2a].The definition of "Normative Portion" may prove useful in this context [1]Some OASIS TCs (IIRC) have created Work Products that have collections of XSDs, Relax-NG schemas, DTDs, and sometimes also Schematron files -- which express co-constraints that the other grammar-based formalisms cannot express. These collections of validation files ("computer language definitions") were declared NOT "Normative Portion" content, viz., computer language definition files that are NOT "[Nn]ormative" because - among other things, the different grammar and non-grammar formalisms express different kind of constraints. All are useful, but the fact that one formalism throws no error on validation pass -- while another DOES throw an error -- is to be expected. I may have even seen examples (IIRC) where a precedence order was given, but I think it's just been more common to say that "neither DTS, XSDs, RNG, or Schematron are 'Normative': they are just advisory.- rcc[1a] Normative Portion"Normative Portion - a portion of an OASIS Standards Final Deliverable that must be implemented to comply with such deliverable. If such deliverable defines optional parts, Normative Portions include those portions of the optional part that must be implemented if the implementation is to comply with such optional part. Examples and/or reference implementations and other specifications or standards that were developed outside the TC and which are referenced in the body of a particular OASIS Standards Final Deliverable that may be included in such deliverable are not Normative Portions."[2a]Wunder, John A. wrote this message on Mon, Apr 11, 2016 at 11:23 +0000:> Another comment is that I’ve seen people using the term "normative" in relation to the schemas. I used to think the schemas would be normative too but was convinced otherwise. Schemas should be informative -- that way you can resolve disagreements between the schemas and the text specifications in favor of the text specifications and ensure consistency across all of the serializations (MTI and otherwise). This is how MITRE has done other specs as well, and is how TAXII 1.1’s XML Binding Specification is written.I agree, the spec is the only normative definition. The schema helpsvalidate adherence to the spec, but the schema should not be considerednormative.. It is possible that the schema cannot be as strict as thespecification says, so therefore the specification must be the finalarbiter..On Tue, Apr 12, 2016 at 12:36 PM, Jordan, Bret <bret.jordan@bluecoat.com> wrote: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,BretBret Jordan CISSPDirector of Security Architecture and Standards | Office of the CTOBlue Coat SystemsPGP 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./chetOn 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--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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]