Issue 6024: Any mapping in XML is too verbose (deployment-ftf) Source: Zuehlke Engineering (Mr. Frank Pilhofer, fpilhofer2008(at)gmail.com) Nature: Uncategorized Issue Severity: Summary: The current mapping for the Any type in the PSM for CCM for XML (section 9.5.4, page 117 in ptc/03-07-08) is very verbose, for example an execution parameter property looks like <execParameter> <name>entrypoint</name> <value> <type> <simple> <type>string</type> </simple> </type> <value> <value> <value>main</value> </value> </value> </value> </execParameter> While not quite "broken," the mapping could be simplified - and made less intimidating to those who prefer looking at XML code in a text editor - by not separating the DataType from the DataValue, but by combining them. An updated UML diagram for a better mapping of the Any type is attached - it would eliminate the DataValue type. By including an "Opaque" element of "base64Binary" type, this mapping includes a potential resolution for 5993. According to this updated mapping, the execution parameter above would look like <execParameter> <name>entrypoint</name> <value> <simple> <type>string</type> <value>main</value> </simple> </value> </execParameter> Resolution: Revised Text: Actions taken: July 28, 2003: received issue Discussion: End of Annotations:===== Subject: Any mapping in XML is too verbose Date: Mon, 28 Jul 2003 15:17:29 -0400 X-MS-Has-Attach: yes Thread-Topic: Any mapping in XML is too verbose Thread-Index: AcNVPOOSJDURANb9RLGT2Q4hmaKS2g== From: "Pilhofer, Frank" To: Cc: This is a suggestion for the Deployment FTF. The current mapping for the Any type in the PSM for CCM for XML (section 9.5.4, page 117 in ptc/03-07-08) is very verbose, for example an execution parameter property looks like entrypoint string main While not quite "broken," the mapping could be simplified - and made less intimidating to those who prefer looking at XML code in a text editor - by not separating the DataType from the DataValue, but by combining them. An updated UML diagram for a better mapping of the Any type is attached - it would eliminate the DataValue type. By including an "Opaque" element of "base64Binary" type, this mapping includes a potential resolution for 5993. According to this updated mapping, the execution parameter above would look like entrypoint string main Frank new-any.gif Subject: Issue 6024 proposed resolution Date: Thu, 4 Sep 2003 17:31:51 -0400 X-MS-Has-Attach: yes Thread-Topic: Issue 6024 proposed resolution Thread-Index: AcNzK/SELk4Q9QqpSueMvr4I821SUQ== From: "Pilhofer, Frank" To: Hi all, I was tasked to propose a concrete resolution for issue 6024, "Any mapping in XML is too verbose." In the last telecom, I outlined a solution where the DataType and DataValue classes would be merged. After some reflection, I decided that this wouldn't be a good route to take. The XML would be simpler, but the implementation would have to be more complex. Since the DynamicAny interface requires a complete typecode before any data can be added, the parser would need two passes over the same data. What's worse, the code to parse a TypeCode would have to exist twice, once for standalone typecodes, once for typecodes as part of an Any. Therefore, the current Any mapping, as a composition of a DataType and a DataValue (as on page 117) should be kept. However, both DataType and DataValue can be simplified. DataType itself should include a "kind" attribute as a discriminator of its contents (rather than placing this attribute in its own SimpleType class). DataValue can also include a "simple" attribute of its own, to represent simple values. So my proposal is - In section 9.5.5, "DataType," replace the diagram with the attached one. Replace the second paragraph of 9.5.5 with The DataType class contains a "kind" field that indicates the IDL type described by the DataType. It can contain any value from the CORBA::TCKind enumeration, without the "tk_" prefix (i.e. short, long etc.). If the kind is "struct" or "value," then the DataType contains a StructType element to describe the composition of the struct or valuetype. Valuetypes are expected to have public members only. If the kind is "array" or "sequence," then the DataType contains a SequenceType element, with its bound attribute indicating the array size or the sequence bound (0 if unbounded). If the kind is "enum," the DataType contains an EnumType element. In section 9.5.6, "DataValue," replace the diagram with the attached one. Replace its description with The DataValue class describes a value. It is mapped to a hierarchichal structure as above, fully describing a value that can be described by an IDL type. A DataValue cannot exist by itself, it needs a matching DataType to describe its structure (see the Any class). If the DataType kind is short, long, ushort, ulong, float, double, string, longlong, ulonglong, longdouble or wstring, then the simple attribute contains a stringified representation of the value. If the DataType kind is char or wchar, then the simple attribute contains a string of length 1. If the DataType kind is boolean, then the simple attribute contains one of the values "0", "1", "false" or "true". If the DataType kind is octet, then the simple attribute contains a stringified integer value in the range 0 to 255. If the DataType kind is enum, then the simple attribute contains one of the legal enumeration values. If the DataType kind is objref, then the simple attribute contains a stringified object reference. If the DataType kind is struct or value, then the DataValue contains a StructValue element describing the values of all struct or valuetype members. If the DataType kind is array or sequence, then the DataValue contains a SequenceValue element describing the values of all array or sequence elements. (Note the exception for sequences of octet below.) If the DataType kind is any, then the DataValue contains a DataType element. If the DataType kind is typecode, then the DataValue contains an Any element. If the DataType kind is sequence, and the sequence's element type's kind is octet, then the DataValue contains an OpaqueValue element. Note that this resolution is longer than the existing text also because it is more explicit than before. See y'all in Boston next week, Frank new-datatype.gif Subject: Issue 6024 updated proposed resolution Date: Mon, 15 Sep 2003 12:16:20 -0400 X-MS-Has-Attach: yes Thread-Topic: Issue 6024 proposed resolution Thread-Index: AcNzLCxUg6q/dDC5TvurAME6K9ODbwIYmELQ From: "Pilhofer, Frank" To: Hi, after the discussion at the OMG meeting, where we decided that the existing schema datatypes (xsd:short, xsd:long etc.) should be used, I decided to revisit this issue and to do it "right." If there is no precedent for representing an Any in XML that we can copy from, then we should define a class that can be reused by others. The attached DataType class can accurately represent any kind of type code (including unions, value boxes, aliased types and typed object references). The DataValue class reuses types defined by the XML schema specification. Sequences of basic types are represented using arbitrary multiplicities of these types. So here's the updated proposed resolution. In section 9.5.5, "DataType," replace the diagram with the attached one. Replace the second paragraph of 9.5.5 with The DataType class contains a "kind" field that indicates the IDL type described by a DataType instance. kind is of the enumeration type CORBA::TCKind, as defined in section 4.11 of the CORBA specification. If the kind is tk_null, tk_void, tk_short, tk_long, tk_ushort, tk_ulong, tk_float, tk_double, tk_boolean, tk_char, tk_octet, tk_any, tk_TypeCode, tk_longlong, tk_ulonglong, tk_longdouble or tk_wchar, the DataType element does not contain any other elements. If the kind is tk_string or tk_wstring, then the DataType may optionally contain a BoundedStringType element indicating the upper bound for the string length. If the DataType does not contain a BoundedStringType, an unbounded string is assumed. If the kind is tk_objref, tk_component or tk_home, then the DataType may optionally contain an ObjrefType element describing the object reference's type (using its Repository Id). If the DataType does not contain an ObjrefType element, then an untyped object reference (Repository Id "IDL:omg.org/CORBA/Object:1.0") is assumed. If the kind is tk_struct or tk_except, then the DataType contains a StructType element, which in turn describes a list of struct members. If the kind is tk_union, then the DataType contains a UnionType element. UnionType contains the type of the descriminator and a number of typed elements, one of which may be the default member. Each member may be identified with multiple case labels. No label is associated with the default member. If the kind is tk_enum, then the DataType contains an EnumType element describing the enumeration values. If the kind is tk_sequence, then the DataType contains a SequenceType element. Its optional bound attribute indicates the sequence's upper bound. If the bound attribute is absent, the sequence is unbounded. If the kind is tk_array, then the DataType contains an ArrayType element. Its length attribute indicates the length of the array. For multi-dimensional arrays, the multiplicity of the length attribute is greather than one, and the most significant dimension is listed first ("left to right" in IDL). If the kind is tk_alias or tk_value_box, then the DataType contains an AliasType element. If the kind is tk_fixed, then the DataType contains a FixedType element. If the kind is tk_value, then the DataType contains a ValueType element. ValueType contains the type code of the concrete base type, if any, a type modifier (with values as defined by CORBA::ValueModifier), and a number of members. Each member has a name, type and visibility (with values as defined by CORBA::Visibility). In section 9.5.6, "DataValue," replace the diagram with the attached one. Replace its description with The DataValue class describes a value. It is mapped to a hierarchichal structure as above, fully describing a value that can be described by an IDL type. A DataValue cannot exist by itself, it needs a matching DataType to describe its structure (see the Any class). If the type's kind is tk_null or tk_void, DataValue is empty. If the type's kind is tk_short, tk_long, tk_ushort, tk_ulong, tk_float, tk_double, tk_boolean, tk_octet, tk_string, tk_longlong, tk_ulonglong, or tk_longdouble, DataValue contains a single short, long, ushort, ulong, float, double, boolean, octet, string, longlong, ulonglong or longdouble attribute, respectively. If the type's kind is tk_wstring, then DataValue also contains a string element. If the type's kind is tk_char or tk_wchar, the DataValue contains a string attribute containing a string of length 1. If the type's kind is tk_enum, the DataValue contains the enumeration value in the enum attribute. If the type's kind is tk_objref, tk_component or tk_home, the DataValue contains a stringified object reference in the objref attribute. If the type's kind is tk_fixed, the DataValue contains a fixed attribute holding a fixed-point decimal literal. If the type's kind is tk_sequence or tk_array, and the sequence's or array's element type is equivalent to (i.e. not considering aliased types) tk_short, tk_long, tk_ushort, tk_ulong, tk_float, tk_double, tk_boolean, tk_octet, tk_objref, tk_enum, tk_string, tk_longlong, tk_longlong, tk_ulonglong, tk_longdouble, tk_wstring tk_fixed, tk_component or tk_home, then the respective attribute has a multiplicity equal to the length of the sequence or array. In the case of multi-dimensional arrays, the least significant dimension is enumerated first. If the type's kind is tk_sequence or tk_array, and the sequence's or array's element type is equivalent to tk_char or tk_wchar, then the DataValue contains a single string attribute. Each character in this string is used as an element of the sequence or array. If the type's kind is tk_sequence or tk_array, and the sequence's or array's element type is equivalent to tk_octet, then the DataValue contains a single opaque attribute. If the type's kind is tk_sequence or tk_array, and the sequence's or array's element is not of the types enumerated above, then the DataValue contains the elements of the sequence or array as DataType elements, using the element association. If the type's kind is tk_TypeCode or tk_any, the DataValue contains a DataType or Any element, respectively. If the type's kind is tk_struct or tk_value, the DataValue contains a NamedValue for each member of the struct or valuetype. If the type's kind is tk_union, the DataValue contains a single DataValue as the union's discriminator, and zero or one DataValue elements, using the value association, as the member of the union. If the type's kind is tk_value_box, the DataValue contains zero or one DataValue elements using the boxedValue association. If the boxedValue element is missing, a null value is implied. Phew. Long but hopefully complete. Frank new-datatype1.gif new-datavalue1.gif :wq new-datavalue.gif From: Subject: Re: Deployment FTF voting (1st poll), closing 20th October 2003 20:00 GMT To: deployment-ftf@omg.org X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Date: Fri, 17 Oct 2003 09:54:41 -0500 X-MIMETrack: Serialize by Router on CollinsCRSMTP02/CedarRapids/RockwellCollins(Release 5.0.10 |March 22, 2002) at 10/17/2003 09:54:43 AM Please vote with Yes/No/Abstain for each issue resolution, as detailed in the attachment. Note: A short reason for No votes is mandatory. OMG Issue No: 5953: Yes. OMG Issue No: 5954: Yes. OMG Issue No: 5955: No. - Not sufficient rationale/justification for adding this additonal complexity. No example of problem being solved by adding this new class. OMG Issue No: 5956: Yes. OMG Issue No: 5957: Yes. OMG Issue No: 5958: Yes. OMG Issue No: 5959: Yes. OMG Issue No: 5960: Yes. OMG Issue No: 5961: Yes. OMG Issue No: 5962: Yes. OMG Issue No: 5963: No. - UUID's, Labels, Attributes should not be optional. The Attributes should clearly be required if needed. This solution causes confusion and presents difficulties for tools and applications to anticipate appropriate actions. OMG Issue No: 5964: Yes. OMG Issue No: 5983: Yes. OMG Issue No: 5984: Yes. OMG Issue No: 5985: Yes. OMG Issue No: 5986: Yes. OMG Issue No: 5993: No. Voting No on Issue 6024 requires a different solution for this issue. OMG Issue No: 6024: No. Solution allows/causes XML parsing errors. Need to re-think this solution so that validating parsers work with the XML. OMG Issue No: 6037: Yes. OMG Issue No: 6038: Yes. OMG Issue No: 6041: Yes. OMG Issue No: 6042: Yes. OMG Issue No: 6044: Yes. OMG Issue No: 6046: Yes. OMG Issue No: 6048: Yes. OMG Issue No: 6051: Yes. OMG Issue No: 6052: Yes. ------------------- snip -------------------- Andreas Hoffmann unhofer.de> cc: Subject: Deployment FTF voting (1st poll), closing 20th October 2003 20:00 GMT 10/02/2003 10:07 AM Hi FTF members, this is the first voting for the OMG Deployment FTF. For details on the issue resolutions please refer to the attached document listing all the issue resolutions of this voting. Compared to Tuesday's draft version I have added issue 5962 and moved issues 5993, 6044 and 6052 from "Resolved" to "Duplicate or merged". Anyway, this classification has no impact on the voting. In order to give all FTF members enough time to study the issue resolutions and their impacts on the specification the voting deadline is Monday 20th October, 2003, 20:00 GMT. ------------------- snip -------------------- ** Deployment FTF Voting Poll 1 ** ** Voting Deadline October 20, 2003, 20:00 GMT ** Company: Voter: Regards Andreas ==================================================================== Andreas Hoffmann Fraunhofer FOKUS - Research Institute for Open Communication Systems Kaiserin-Augusta-Allee 31 D - 10589 Berlin Phone: +49 30 3463-7392 Fax: +49 30 3463-8392 Email: andreas.hoffmann@fokus.fraunhofer.de ==================================================================== (See attached file: omg-deployment-ftf-01_10_03.zip) omg-deployment-ftf-01_10_031.zip Date: Fri, 17 Oct 2003 17:38:29 -0400 From: James Kulp Organization: Mercury Computer Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en,pdf To: dahaverk@rockwellcollins.com CC: deployment-ftf@omg.org Subject: Re: Deployment FTF voting (1st poll), closing 20th October 2003 20:00 GMT Dave, I'll just try to provide a bit more explanation for the issues you didn't find acceptable (since Frank is out today). It is unfortunate that some of these issues were not raised during our discussions - or in email dialog. dahaverk@rockwellcollins.com wrote: Please vote with Yes/No/Abstain for each issue resolution, as detailed in the attachment. Note: A short reason for No votes is mandatory. OMG Issue No: 5953: Yes. OMG Issue No: 5954: Yes. OMG Issue No: 5955: No. - Not sufficient rationale/justification for adding this additonal complexity. No example of problem being solved by adding this new class. This was an issue where the class in question was being used in two places, but it turned out that it was not appropriate to re-use - thus rather than using the ComponentPackageReference class in two places, the case of using it as an implementation dependency was incorrect. It previously indicated such dependencies as pointers to implementations (ComponentPackageReference). The change specifies the dependency in a way that is simpler and lighter: that an application of a certain type had to be running, but not necessarily one that the implementer knew a package reference (implementation pointer) for. So the "complexity" of the extra class that has a single string attribute allows the dependency to be simpler, and more flexible - indicate an interface, not an implementation OMG Issue No: 5956: Yes. OMG Issue No: 5957: Yes. OMG Issue No: 5958: Yes. OMG Issue No: 5959: Yes. OMG Issue No: 5960: Yes. OMG Issue No: 5961: Yes. OMG Issue No: 5962: Yes. OMG Issue No: 5963: No. - UUID's, Labels, Attributes should not be optional. The Attributes should clearly be required if needed. This solution causes confusion and presents difficulties for tools and applications to anticipate appropriate actions. This issue as written simply says that attributes that are already optional in the spec should be expressed in a more consistent and better way. It is not making any attributes optional. If you think certain attributes in the spec should or should not be optional, that is a separate issue. UUIDs and labels were just used as examples. OMG Issue No: 5964: Yes. OMG Issue No: 5983: Yes. OMG Issue No: 5984: Yes. OMG Issue No: 5985: Yes. OMG Issue No: 5986: Yes. OMG Issue No: 5993: No. Voting No on Issue 6024 requires a different solution for this issue. Indeed this could have been specified in a standalone way since the issue 6024 change simply solved this by replacing a MIME reference to base64 encoding with the xsd:base64Binary instead -- which is already built in to XML schemas - obviating the MIME reference. OMG Issue No: 6024: No. Solution allows/causes XML parsing errors. Need to re-think this solution so that validating parsers work with the XML. Per your email with Frank, we'll have to figure out whether this is a problem with the schema or a problem with your tools. No specific error in the schema was identified. I'll try to look at this further tomorrow (Saturday). The tool you use is evidently available for a free trial! Jim OMG Issue No: 6037: Yes. OMG Issue No: 6038: Yes. OMG Issue No: 6041: Yes. OMG Issue No: 6042: Yes. OMG Issue No: 6044: Yes. OMG Issue No: 6046: Yes. OMG Issue No: 6048: Yes. OMG Issue No: 6051: Yes. OMG Issue No: 6052: Yes. ------------------- snip -------------------- Andreas Hoffmann unhofer.de> cc: Subject: Deployment FTF voting (1st poll), closing 20th October 2003 20:00 GMT 10/02/2003 10:07 AM Hi FTF members, this is the first voting for the OMG Deployment FTF. For details on the issue resolutions please refer to the attached document listing all the issue resolutions of this voting. Compared to Tuesday's draft version I have added issue 5962 and moved issues 5993, 6044 and 6052 from "Resolved" to "Duplicate or merged". Anyway, this classification has no impact on the voting. In order to give all FTF members enough time to study the issue resolutions and their impacts on the specification the voting deadline is Monday 20th October, 2003, 20:00 GMT. ------------------- snip -------------------- ** Deployment FTF Voting Poll 1 ** ** Voting Deadline October 20, 2003, 20:00 GMT ** Company: Voter: Regards Andreas ==================================================================== Andreas Hoffmann Fraunhofer FOKUS - Research Institute for Open Communication Systems Kaiserin-Augusta-Allee 31 D - 10589 Berlin Phone: +49 30 3463-7392 Fax: +49 30 3463-8392 Email: andreas.hoffmann@fokus.fraunhofer.de ==================================================================== (See attached file: omg-deployment-ftf-01_10_03.zip) Subject: Re: Deployment FTF voting (1st poll), closing 20th October 2003 20:00 GMT To: deployment-ftf@omg.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: Gerald_L_Bickle@raytheon.com Date: Mon, 20 Oct 2003 09:45:46 -0500 X-MIMETrack: Serialize by Router on NotesServer3/HDC(Release 5.0.12 |February 13, 2003) at 10/20/2003 09:44:34 AM OMG Issue No: 5953: Yes. OMG Issue No: 5954: Yes. OMG Issue No: 5955: No. - Not clear why another class is needed. Changing the meaning of depends on. It seems like there is different dependencies types, loading, execution, uses. This needs further thought with use cases and use case realizations to show justification. OMG Issue No: 5956: Yes. OMG Issue No: 5957: Yes, but diagrams need to be updated too OMG Issue No: 5958: Yes. OMG Issue No: 5959: Yes., chapter misspelled in 1st change OMG Issue No: 5960: Yes. OMG Issue No: 5961: no, what is the relationships between this and the install operation. What is the outcome of a createpackage? OMG Issue No: 5962: Yes. OMG Issue No: 5963: No. - It appears the changes are being made to agree with the corresponding text. I don't think the text is correct. These attributes should not be optional. OMG Issue No: 5964: NO, Which issue change has precedence 5957? No mention of updating corresponding diagrams. Without updated diagrams with text changes it is unclear why all these changes are necessary and how all these changes fit together. OMG Issue No: 5983: Yes. OMG Issue No: 5984: Yes. OMG Issue No: 5985: Yes. OMG Issue No: 5986: Yes. OMG Issue No: 5993: Yes if this valid for XML and transformation rules. solution for this issue. OMG Issue No: 6024: Yes, provided the XML is valid syntax. OMG Issue No: 6037: Yes. OMG Issue No: 6038: Yes. OMG Issue No: 6041: Yes. OMG Issue No: 6042: Yes OMG Issue No: 6044: Yes. OMG Issue No: 6046: Yes. OMG Issue No: 6048: Yes. OMG Issue No: 6051: Yes. OMG Issue No: 6052: Yes. Jerry Bickle Senior Principal Software Engineer Network Centric Systems 1010 Production Rd Fort Wayne, IN 46808-4711 260-429-6280 260-429-5060 Fax m: "Francis Bordeleau" To: "Andreas Hoffmann" , "Deployment FTF" Subject: RE: Deployment FTF voting (1st poll), closing 20th October 2003 20:00 GMT Date: Mon, 20 Oct 2003 20:52:25 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal Hi All, No, I am not dead! I apologize for having been out of the loop since the Paris meeting, but I have completely swamped with different things (different project funding propositions, software radio submission, graduate student projects, ...) and it seems that I had a meeting every morning when there was a teleconf, and did not have any meetings the other Wednesdays. Anyway, here is my vote. I should be back on the active mode from now on. I am sorry for sending this email 6 hours after the official end of the poll, but I am at the UML conference this week and there are no internet connections in the location where we are today for the workshops (and I was expecting to be able to send it when coming in this morning). So I had to wait until I come back to the hotel to send the email. I left a voice message to Frank at Mercury to let him know. Hopefully, my vote can still be considered. Thanks, Francis OMG Issue No: 5953: YES OMG Issue No: 5954: YES OMG Issue No: 5955: ABSTAIN. I do not see what problem the new solution solves. The issue is not very well described. So in summary, I abstain instead of voting "NO" because I am guilty of not having participated to the discussion. OMG Issue No: 5956: YES OMG Issue No: 5957: YES OMG Issue No: 5958: YES OMG Issue No: 5959: YES OMG Issue No: 5960: YES. However, we should explicitly mention that the current specification does not address the implementation selection issue. OMG Issue No: 5961: NO. I think that the solution might be right, but the argument is too weak. Not convincing at all. E.g. " It might be useful to have ...", This method would do less than" (please explain). OMG Issue No: 5962: YES OMG Issue No: 5963: YES OMG Issue No: 5964: NO. I do not see how changing "label" for "name" solves the problem. OMG Issue No: 5983: YES OMG Issue No: 5984: YES OMG Issue No: 5985: YES OMG Issue No: 5986: YES OMG Issue No: 5993: YES OMG Issue No: 6024: ABSTAIN. I am not sure of the implication of this change. Any impact? OMG Issue No: 6037: YES OMG Issue No: 6038: YES OMG Issue No: 6041: YES OMG Issue No: 6042: YES OMG Issue No: 6044: YES OMG Issue No: 6046: YES OMG Issue No: 6048: YES OMG Issue No: 6051: YES OMG Issue No: 6052: YES ------------------- snip -------------------- Regards Andreas ==================================================================== Andreas Hoffmann Fraunhofer FOKUS - Research Institute for Open Communication Systems Kaiserin-Augusta-Allee 31 D - 10589 Berlin Phone: +49 30 3463-7392 Fax: +49 30 3463-8392 Email: andreas.hoffmann@fokus.fraunhofer.de ====================================================================