CybOX - Conformance comment - TAB

[Patrick Durusau <patrick@durusau.net>]

Greetings!

Apologies but there wasn't a listing for CybOX Version 2.1.1 in JIRA
when comments were due.

Priority: Blocker

CybOX version 2.1.1. Part 01: Overview, provides in part:

> 5 Conformance
> 
> Implementations have discretion over which parts (components, properties, extensions, controlled vocabularies, etc.) of CybOX they implement (e.g., Observable/Object).
> 
> [1] Conformant implementations must conform to all normative structural specifications of the UML model or additional normative statements within this document that apply to the portions of CybOX they
> implement (e.g., Implementers of the entire Observable class must conform to all normative structural specifications of the UML model regarding the Observable class or additional normative statements
> contained in the document that describes the Observable class).
> 
> [2] Conformant implementations are free to ignore normative structural specifications of the UML model or additional normative statements within this document that do not apply to the portions of CybOX they
> implement (e.g., Non-implementers of any particular properties of the Observable class are free to ignore all normative structural specifications of the UML model regarding those properties of the Observable class or additional normative statements contained in the document that describes the Observable class).
> 
> The conformance section of this document is intentionally broad and attempts to reiterate what already exists in this document.
> 

That is, by no stretch of the imagination, NOT a conformance clause.

First, the OASIS TC process rather clearly provides:

> (8a) For Standards Track Work Products:
> 
> A specification that is approved by the TC at the Committee Specification Public Review Draft, Committee Specification or OASIS Standard level must include a separate section, listing a set of numbered conformance clauses, to which any implementation of the specification must adhere in order to claim conformance to the specification (or any optional portion thereof).

There are no details in this "conformance" clause either here and/or the
many times it is repeated verbatim (I didn't check all instances, the
ones I saw) throughout the many parts of this effort.

Second, this isn't the first time the TC's inability to write meaningful
conformance clauses has surfaced. Rather than mock TCs that do labor to
produce meaningful conformance clauses, you really should delete these
pseudo-conformance clauses and simply say you have none.

Perhaps the OASIS administration will progress it anyway. I can't say
but it would be more honest than the approach taken here.

Third, I can illustrate the consequences of this type of "conformance"
clause and the poor requirements that make up this voluminous work.

Perhaps you have heard of JSON? Did you know that no two JSON parsers,
due to the lengthy and poor standardization of JSON are 100% compatible?

Don't take my word for it. See: http://seriot.ch/parsing_json.html

I have attached the image from that work for your review.

Print that image out in color, perhaps enlarged a bit and ask your
sponsors if that is the level of incompatibility they want for with CybOX?

I suspect their answer may surprise you.

I could go on and on about the details but unless and until conformance
(which includes all the other prose, references, etc.) becomes a
priority for the TC, what's the point?

Hope you are at the start of a great weekend!

Patrick


-- 
Patrick Durusau
patrick@durusau.net
Technical Advisory Board, OASIS (TAB)
OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor 13250-5 (Topic Maps)

Another Word For It (blog): http://tm.durusau.net
Homepage: http://www.durusau.net
Twitter: patrickDurusau

Attachment: jason-parser-tests.png
Description: PNG image

Attachment: signature.asc
Description: OpenPGP digital signature