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

 


Help: OASIS Mailing Lists Help | MarkMail Help

csaf message

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


Subject: [CSAF JSON schema] what to do about extensibility of JSON


More specifically, my question is whether the specification of a JSON format should say anything about extensions / extensibility and conformance?

I don't have any specific answers here, just some questions.

Assumption - we'll require the "$schema" property at the top of one of these JSON-syntax CSAF documents, in order to tie it to a specific version of the specification. That's a good start, because it essentially tells the parsing logic how to treat the rest of the document. However, assuming for a moment that a vendor has introduced extensions - can the vendor specify an alternate schema in some way to make sure all the additional properties the vendor has added also get added?

JSON schema, in a flip from what XML does, mostly just ignores what it sees that is not defined in the schema. However, JSON schema does have the "propertyNames" constraint - which limits what is allowed in a particular "object". Is it desirable to use "propertyNames" everywhere in the CSAF JSON schema? Is it desirable to use it some times?

Do we want to set up a requirement about how to label extensions? Specifically, if a vendor adds an element to the instance document that isn't part of the official specification, does the vendor need to indicate that. Analogy is the "X-" HTTP headers. In JSON, this would probably be "x_"... labeled properties.

Conformance: Do we want a requirement on any processor that alters an existing JSON document that it preserve all extension elements present in the document?

Eric.



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