Common Terminology Services 2 Avatar
  1. OMG Specification

Common Terminology Services 2 — Closed Issues

  • Acronym: CTS2
  • Issues Count: 14
  • Description: Issues resolved by a task force and approved by Board
Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
CTS212-26 OMG Architecture Board review issues, Nov 2013 CTS2 1.1 CTS2 1.2 Resolved closed
CTS212-25 The reference in B4 should instead be added to section 3 (assuming it is normative) CTS2 1.1 CTS2 1.2 Resolved closed
CTS212-24 Rule 10 example uses xsi2:nill – I think this should be xsi2:nil (only one L) CTS2 1.1 CTS2 1.2 Resolved closed
CTS212-23 conflict between rules 10 and 13 CTS2 1.1 CTS2 1.2 Resolved closed
CTS212-22 Rule 10 does not cover the case where the removal of namespaces causes names to be indistinguishable CTS2 1.1 CTS2 1.2 Resolved closed
CTS212-21 The following in rule 10 is very unclear “In certain situations, this may cause issues for opaque data” CTS2 1.1 CTS2 1.2 Resolved closed
CTS212-20 issue with rule 10 CTS2 1.1 CTS2 1.2 Resolved closed
CTS212-19 The documents referenced in Rule 12 should appear in the normative references section CTS2 1.1 CTS2 1.2 Resolved closed
CTS212-18 B2 rule 7: I’m not aware of such a thing as an “XML array” CTS2 1.1 CTS2 1.2 Resolved closed
CTS212-17 Section 7 has the wrong document number for CTS2 – it should be formal/13-12-01 CTS2 1.1 CTS2 1.2 Resolved closed
CTS212-16 The Normative References in section 3 must be added to the Normative References section in the main CTS2 spec CTS2 1.1 CTS2 1.2 Resolved closed
CTS212-15 the “Plan” in 6.2 with the RTF working in parallel is not being followed at all CTS2 1.1 CTS2 1.2 Resolved closed
CTS212-14 No Beta document CTS2 1.1 CTS2 1.2 Resolved closed
CTS212-13 Section 1: should rephrase “this submission” – it’s now a specification CTS2 1.1 CTS2 1.2 Resolved closed

Issues Descriptions

OMG Architecture Board review issues, Nov 2013

  • Key: CTS212-26
  • Legacy Issue Number: 19308
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    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.

  • Reported: CTS2 1.1 — Mon, 31 Mar 2014 04:00 GMT
  • Disposition: Resolved — CTS2 1.2
  • Disposition Summary:

    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

  • Updated: Sat, 7 Mar 2015 03:03 GMT

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

  • Key: CTS212-25
  • Legacy Issue Number: 19307
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

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

  • Reported: CTS2 1.1 — Mon, 24 Mar 2014 04:00 GMT
  • Disposition: Resolved — CTS2 1.2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 03:03 GMT

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

  • Key: CTS212-24
  • Legacy Issue Number: 19306
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

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

  • Reported: CTS2 1.1 — Mon, 24 Mar 2014 04:00 GMT
  • Disposition: Resolved — CTS2 1.2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 03:03 GMT

conflict between rules 10 and 13

  • Key: CTS212-23
  • Legacy Issue Number: 19305
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    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

  • Reported: CTS2 1.1 — Mon, 24 Mar 2014 04:00 GMT
  • Disposition: Resolved — CTS2 1.2
  • Disposition Summary:

    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

  • Updated: Sat, 7 Mar 2015 03:03 GMT

Rule 10 does not cover the case where the removal of namespaces causes names to be indistinguishable

  • Key: CTS212-22
  • Legacy Issue Number: 19304
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    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

  • Reported: CTS2 1.1 — Mon, 24 Mar 2014 04:00 GMT
  • Disposition: Resolved — CTS2 1.2
  • Disposition Summary:

    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

  • Updated: Sat, 7 Mar 2015 03:03 GMT

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

  • Key: CTS212-21
  • Legacy Issue Number: 19303
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

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

  • Reported: CTS2 1.1 — Mon, 24 Mar 2014 04:00 GMT
  • Disposition: Resolved — CTS2 1.2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 03:03 GMT

issue with rule 10

  • Key: CTS212-20
  • Legacy Issue Number: 19302
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

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

  • Reported: CTS2 1.1 — Mon, 24 Mar 2014 04:00 GMT
  • Disposition: Resolved — CTS2 1.2
  • Disposition Summary:

    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

  • Updated: Sat, 7 Mar 2015 03:03 GMT

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

  • Key: CTS212-19
  • Legacy Issue Number: 19301
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

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

  • Reported: CTS2 1.1 — Mon, 24 Mar 2014 04:00 GMT
  • Disposition: Resolved — CTS2 1.2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 03:03 GMT

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

  • Key: CTS212-18
  • Legacy Issue Number: 19300
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

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

  • Reported: CTS2 1.1 — Mon, 24 Mar 2014 04:00 GMT
  • Disposition: Resolved — CTS2 1.2
  • Disposition Summary:

    Reworded to clarify the intent

  • Updated: Sat, 7 Mar 2015 03:03 GMT

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

  • Key: CTS212-17
  • Legacy Issue Number: 19299
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

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

  • Reported: CTS2 1.1 — Mon, 24 Mar 2014 04:00 GMT
  • Disposition: Resolved — CTS2 1.2
  • Disposition Summary:

    Fix document number

  • Updated: Sat, 7 Mar 2015 03:03 GMT

The Normative References in section 3 must be added to the Normative References section in the main CTS2 spec

  • Key: CTS212-16
  • Legacy Issue Number: 19298
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    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

  • Reported: CTS2 1.1 — Mon, 24 Mar 2014 04:00 GMT
  • Disposition: Resolved — CTS2 1.2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 03:03 GMT

the “Plan” in 6.2 with the RTF working in parallel is not being followed at all

  • Key: CTS212-15
  • Legacy Issue Number: 19297
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    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.

  • Reported: CTS2 1.1 — Mon, 24 Mar 2014 04:00 GMT
  • Disposition: Resolved — CTS2 1.2
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 03:03 GMT

No Beta document

  • Key: CTS212-14
  • Legacy Issue Number: 19296
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    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

  • Reported: CTS2 1.1 — Mon, 24 Mar 2014 04:00 GMT
  • Disposition: Resolved — CTS2 1.2
  • Disposition Summary:

    Change to “this submission"

  • Updated: Sat, 7 Mar 2015 03:03 GMT

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

  • Key: CTS212-13
  • Legacy Issue Number: 19295
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

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

  • Reported: CTS2 1.1 — Mon, 24 Mar 2014 04:00 GMT
  • Disposition: Resolved — CTS2 1.2
  • Disposition Summary:

    revised

  • Updated: Sat, 7 Mar 2015 03:03 GMT