If isn’t that the artifact is considered the final and complete, it is that if there is a difference, the machine readable artifact wins.
For example we create the foo element, and refer to it as the foo element in the entire narrative and all examples in the MB file.
We misspell it in the machine readable schema, as the fuo.
In that case, where there is a conflict, the fuo wins.
Where there is no conflict the narrative specification wins.
The purpose of this rule is
to enable programmers using integrated development environments (IDEs) to import the artifact and be able to rely on the environment forcing them to make correct messages (by tyoe0-ahead
and others)
to enable automated testing of valid messages
to enable specification aware firewalls and pre-processors to block malformed messages (especially important for a security environment)
There may be more.
But this is a first public review. Slowing down the pace of writing to look carefully at the schema is a great public review activity. None of this slows down pushing this set of documents and artifacts to public review.
tc
From: <>
On Behalf Of duncan sfractal.com
Sent: Friday, October 19, 2018 5:14 PM
To: Chet Ensign <>; TC OpenC2 <>
Cc: Paul Knight <>
Subject: Re: [openc2] One item I've noticed on the current CSDs that will need to be fixed
Sorry it accidentally sent too soon
Chet,
I do have a question. One of the reasons for the discussion and the ‘text beats schema’ wording is that the schema is not as complete as the text (at least in the Language Spec). In particular there are statements in the text not represented
in the schema. If the schema is the ‘more normative’ text, would that mean the additional text constraints do not need to be met?
iPhone, iTypo, iApologize
Duncan Sparrell
sFractal Consulting, LLC
I welcome VSRE emails. Learn more at
http://vsre.info/
From: duncan sfractal.com <>
Sent: Friday, October 19, 2018 17:11
To: Chet Ensign; TC OpenC2
Cc: Paul Knight
Subject: Re: [openc2] One item I've noticed on the current CSDs that will need to be fixed
Chet,
I do have a question. One of the reasons for the discussion and the ‘text beats schema’ wording is that the schema is not as complete as the text (at least in the Language Spec). In particular there are statements in the text not represented
in the schema. If the schema is the ‘more normative’ text, then
iPhone, iTypo, iApologize
Duncan Sparrell
sFractal Consulting, LLC
I welcome VSRE emails. Learn more at
http://vsre.info/
From:
<> on behalf of Chet Ensign <>
Sent: Friday, October 19, 2018 5:01:09 PM
To: TC OpenC2
Cc: Paul Knight
Subject: [openc2] One item I've noticed on the current CSDs that will need to be fixed
Hi members of the OpenC2 TC,
We are preparing the OpenC2 Stateless Packet Filtering v1.0 csd03 right now and I noticed a technical issue that will have to be addressed before it can go forward for public review. (This may apply to others as well which is why I'm letting
you know now.)
Annex B OpenC2 Schema contains a schema. Whenever a spec contains normative computer-readable files like schemas, the package must include separate plain text copies of those files. In addition, if there is a discrepancy between the copy
in the document and the separate file, the plain text file is authoritative. (The CSD reads "This annex is normative, however in the event of a conflict with the schema in the OpenC2 Language Specification, the Language Specification is authoritative." So
this annex schema will have to be provided as plain text and the Lang. Spec. will have to be as well.)
This is explained in sect 2.2.5 of the TC Process. (https://www.oasis-open.org/policies-guidelines/tc-process-2017-05-26#workProdComponents)
Let me know if you have any questions...
Best,
/chet
----------------
Chet Ensign
Chief Technical Community Steward
OASIS: Advancing open standards for the information society
http://www.oasis-open.org
Primary: +1 973-996-2298
Mobile: +1 201-341-1393
