Re: [csaf] CSAF JSON Schema - specifying the language of the document?

Thank you very much for your time and help on this! I agree on your suggestion (option B), but will let others comment. You are absolutely correct, this was a consequence of auto-conversion from XML that uses the "xml:lang" attribute.

Regards,

Omar Santos

PSIRT, Security Research and Operations

Cisco Systems, Inc.

Email: os@cisco.com

PGP Key: 0x3AF27EDC

From: <csaf@lists.oasis-open.org> on behalf of Eric Johnson <eric@tibco.com>
Date: Wednesday, May 2, 2018 at 1:31 PM
To: "csaf@lists.oasis-open.org" <csaf@lists.oasis-open.org>
Subject: [csaf] CSAF JSON Schema - specifying the language of the document?

One of the sample documents we have includes snippets like this:

"document_title": {

"lang": "en",

"text": "Red Hat Bug Fix Advisory: Red Hat OpenShift Container Platform 3.9 RPM Release Advisory"

[Example 1]

This makes sense as a consequence of conversion from XML that uses the "xml:lang" attribute. However, it maps poorly to JSON, where what was a simple "string" element containing a title now becomes an object with two properties.

The other document looks like this:

"document_title": "Cisco IOS and IOS XE Software Smart Install Remote Code Execution Vulnerability",

[Example 2]

(Curiously, unlike an XML Schema equivalent, JSON Schema actually makes it straightforward to support both these cases, but it does not seem desirable.)

The current CVRF 1.2 specification includes the use of "xml:lang" attributes in a few places in examples, but does not specify anything about those attributes. At a minimum, I would hope we would indicate best practices, such as including it only once at the top of the document.

I see several possibilities for how to deal with language indicators:

A - Do nothing - take all indication of language choice out of the JSON format. Leave it to the usage context (for example, HTTP language headers, file name patterns, metadata file stored with JSON files.)

B - Indicate an (optional or required?) language choice for the entire document.

C - Support use of language indicators consistently throughout, wherever there is a string value that could be appropriately translated, also include an indication of language. This option looks like Example 1.

D - Support the use of multiple translations for every string value. A possible implementation of this is:

"document_title": {

"en": "Red Hat Bug Fix Advisory: Red Hat OpenShift Container Platform 3.9 RPM Release Advisory"

"fr": "Avis de correction de bogue de Red Hat: Avis de lancement de RPM de la plate-forme de conteneurs Red Hat OpenShift 3.9"

"de": "Red Hat Bug Fix-Hinweis: Red Hat OpenShift Container Platform 3.9 Versionshinweise für RPM"

(Bad translations courtesy of Google Translate, please forgive me if you speak one of those languages.)

My suggestion is option B - only one language specified for the entire document. This would be consistent with CVRF, which doesn't mention it, and therefore implies just one is expected.

Any objections to my changing the example JSON instances to reflect option B, and change the schema to match?

Eric.

csaf message