This is my OMG Architecture Board review of:

CTS2 XML to JSON Transformation Rules RFC (2nd Rdg) ad/13-09-04
Inventory ad/13-09-05

Here are the comments I did have - mostly minor, and all addressable during finalisation:

1. PDF page 7. For reference, OMG's office has moved: http://www.omg.org/contact.htm

2. Section 1 (Scope), PDF page 8. It would be useful to have definitive references to Badgerfish & Parker, the XML to JSON transformation conventions mentioned. It would also be useful to include one or two sentences explaining why they aren't thought suitable for CTS2 XML.

3. Section 3 (Normative references), PDF page 8. We definitely need a normative reference for JSON. One possibility is IETF RFC 4627 (July 2006):

http://www.ietf.org/rfc/rfc4627.txt

However, it looks as though ECMA has just published a JSON specification as ECMA 404 (an amusing coincidence, no doubt):

http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf

Is either of these an appropriate reference?

4. Section 6.2 (Specification adoption plan), PDF page 9.

The FTF process is designed to accommodate a specification adopted with the intention of merging it into an existing specification, as here. We simply charter an FTF that takes as input both the newly-adopted specification (in this case, the XML to JSON mapping RFC) and the already-adopted specification with which it is being merged (the CTS2 specification), and delivers as its result the merged specification (along with a finalisation report).

In this case, we should simply dissolve the CTS2 1.2 RTF, and charter an FTF that takes the XML/JSON RFC and CTS 1.1 as inputs, and delivers CTS 1.2 (including the JSON mapping) as its result (along with a finalisation report that tracks all the changes made to CTS 1.1 and to the RFC).

This is basically what you have proposed with the "common convenience document", but without the complication of having a separate RTF and FTF.

5. Section 6.4 (Patents containing essential claims). Unfortunately, we can't say that there are definitely none. The best we can say is that there are "none known to the authors". (But that's still useful to know).

6. Section B2 (Transformation patterns and Rules). I'm not an expert, but this all looks reasonable to me. However, "shall" should be used to express the rules instead of "will". For example "Repeating XML attribute values shall be treated as a single JSONValue.", "XML comments and processing instructions shall be ignored.", "The following JSONStringCharacters shall be escaped:" It's just a style issue - the meaning is already clear, and not affected by the change.

1. Address of the OMG office changed in RFC
Delete: Section B4, which referenced the emacs document was deleted and the following normative reference:
The JSON Data Interchange Format 1st Edition / October 2013. http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf
Was added to section 3

The reference in B4 should instead be added to section 3 (assuming it is normative)

The reference in B4 was deleted and a subsequent, normative reference was added to section 3:

Rule 10 example uses xsi2:nill – I think this should be xsi2:nil (only one L)

Change "xsi:nill" to "xsi:nil" in 4 places on Rule 10

Rule 10 does not cover the case where the removal of namespaces causes names to be indistinguishable (that’s the point of namespaces after all). Do such now-identical names then get treated as “arrays” per Rule 7. Or is this disallowed (similar to B3 rule 2)? This needs clarifying

Rule 10 included the statement “This rule is specific to the CTS2 specification. Other OMG specifications may choose the option to keep the namespace.” As, for the time being, this is a CTS2 only specification, the statement above was removed and, instead, a third B3 rule was added

The following in rule 10 is very unclear “In certain situations, this may cause issues for opaque data”

Remove the sentence as it is already addressed in the _CDATA section

Rule 10: it says to remove the “namespace prefixes” but the examples show removal of complete namespace declarations not just the prefix

The previous sentence states “XML namespaces are removed in the JSON.” We have already added the caveat involving _CDATA (issue 19305), but do need to add one additional exception for the root namespace

There seems to be a conflict between rule 10 which seems to state to strip all XML namespaces, and rule 13 which says to retain them if they are in _CDATA

There seems to be a conflict between rule 10 which seems to state to strip all XML namespaces, and rule 13 which says to retain them if they are in _CDATA

The documents referenced in Rule 12 should appear in the normative references section

References added (the first one was already added from Issue 19306)

B2 rule 7: I’m not aware of such a thing as an “XML array”

Reworded to clarify the intent

Section 7 has the wrong document number for CTS2 – it should be formal/13-12-01

Fix document number

The Normative References in section 3 must be added to the Normative References section in the main CTS2 spec. However section 7 does not describe such a change

Add a section to the revision document saying to add a section to the CTS2 document that contains the normative references in the annex.

And in fact the “Plan” in 6.2 with the RTF working in parallel is not being followed at all. The whole section is at variance with reality and people reading this document coming out of the FTF could get very confused as to what is happening.

This had been corrected as an earlier issue reported by Andrew Watson

6.2 references “The FTF beta document” but this is not referenced by document number – nor does it seem to exist as per comments above

Change to “this submission"

Section 1: should rephrase “this submission” – it’s now a specification

revised