+1 on option B.
If “lang”: is to be an optional document-level attribute, I suggest we clearly state a specification default language (of “en"?). Requiring “lang”: is ok too, but likely places more burden on the majority of people using the spec.
Jamison M. Day, Ph.D.
Distinguished Data Scientist
Lookingglass Cyber Solutions, Inc.
This electronic message transmission contains information from LookingGlass Cyber Solutions, Inc. which may be attorney-client privileged, proprietary and/or confidential. The information
in this message is intended only for use by the individual(s) to whom it is addressed. If you believe that you have received this message in error, please contact the sender, delete this message, and be aware that any review, use, disclosure, copying or distribution
of the contents contained within is strictly prohibited.
On May 2, 2018 at 1:23:35 PM, Omar Santos (osantos) (firstname.lastname@example.org) wrote:
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.
PSIRT, Security Research and Operations
Cisco Systems, Inc.
PGP Key: 0x3AF27EDC
From: <email@example.com> on behalf of Eric Johnson <firstname.lastname@example.org>
Date: Wednesday, May 2, 2018 at 1:31 PM
To: "email@example.com" <firstname.lastname@example.org>
Subject: [csaf] CSAF JSON Schema - specifying the language of the document?
One of the sample documents we have includes snippets like this:
"text": "Red Hat Bug Fix Advisory: Red Hat OpenShift Container Platform 3.9 RPM Release Advisory"
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",
(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
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:
"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
"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?