CTS212 — OMG Architecture Board review issues, Nov 2013

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