Issue 18144: Key order should be defined using the @Key annotation
Issue 18145: A @Version annotation shall be added
Issue 18146: Improving Extensible Types
Issue 18292: Proposed type-naming scheme is far from Robust
Issue 18293: Applicable key types not clearly specified
Issue 18294: Typo in opening sentence of section: Missing noun and verb
Issue 18295: Shareable members underspecified
Issue 18296: Typo
Issue 18297: Definition of "strongly assignable" seems to be used inconsitently
Issue 18298: member ID algorithm flawed
Issue 18299: Semantics of overriding an attribute not clearly specified
Issue 18300: TypeObject semantics underspecified and inconsistent
Issue 18301: Type system severely underspecified
Issue 18303: C++ shared member representation breaks safety mechanisms of the struct containing it
Issue 18304: Mapping of Map type underspecified for C
Issue 18305: Not every application limits itself to only 1 representation of a topic
Issue 18306: DataRepresentationQosPolicy is making the application responsible for transport
Issue 18307: Multiplicity mismatch between TypeName and TypeObject
Issue 18308: Topic incosisstency only considered for incompatible types, not for incompatible qos
Issue 18309: lookup_topicdescription semantics make it unusable
Issue 18310: Builtin topics not backward compatible
Issue 18781: ths XSD has many errors
Issue 18144: Key order should be defined using the @Key annotation (dds-xtypes-rtf)
Click here for this issue's archive.
Source: PrismTech (Dr. Angelo Corsaro, PhD., angelo.corsaro(at)prismtech.com)
Nature: Enhancement
Severity: Significant
Summary:
The X-Types specification had left under-defined mechanism to be used for specifying the order of key attributes.
The solution adopted by the FTF was to simply use the member ID to define such an order, but this is not optimal.
We strongly suggest to define @Key annotation as follows:
@Annotation
local interface Key {
attribute unsigned long value;
attribute boolean value default true;
};
Where the value attribute is used to define a total order among the key attributes.
The X-Types specification does not provide any way of attaching version information to topic types. This is unfortunate as this information is quite essential to help debug running systems by identifying which version of the information model each element is working with.
As a consequence a new annotation @Version should be added for topic types. A possible definition of this annotation is shown below:
@Annotation
local interface Version {
attribute unsigned long major;
attribute unsigned long minor;
attribute unsigned long patch_level;
};
Extensible Types do not support monotonic extensions of nested struct types. Adding support for monotonic extensibility of nested structures is straight-forward and requires only a very small change to the existing specification. Our suggestion is to allow for monotonic extensibility at any level in the type structure and accommodate this by serializing a length parameter before any nested structure. No @Id should be serialized since it is likely that user won't specify IDs when using Extensible types and relying on Ids could break the whole scheme.
The naming scheme proposed in section 7.2.2.3.4 is far from Robust, since the prefixes used to identify a collection may clash with the names of a user defined type. For example: what is a user has created a type called sequence_10, and he creates a sequence of 10 elements from this? The resulting typename would then become sequence_10_sequence_10, for which the parser will assume it is now a 2-dimensional sequence without element type. To make robust type names, we should use special characters that are not allowed in the definition of user-defined type names, e.g. sequence<10, sequence_10> or something similar.
In section 7.2.2.3.5.6 it is stated that every member of a struct can act as key. If that is indeed the case, then keys could be set on attributes of type sequence or union for which the resulting behaviour is not clearly specified. (For example, how to compare a key from a sequence of length 1 to a key of a sequence of length 2? How to compare unions that have the same discriminator but different branch values? How to compare unions that have different discriminator values that map onto the same branch?) Either setting keys on sequence and union attributes should be prohibited, or the resulting behaviour should clearly be specified.
The opening sentence seems to be missing a noun and a verb. Probably what is meant is: System developers frequently require the ability to inject their own output into <code> that <is> produced by a Type Representation compiler.
There are some questions regarding shared members that should clearly be addressed in this section: * Are shareable members always implemented as pointers in the way optional members are? * If so, can a shareable member be NULL? * If so, then is a shareable member not by definition also an optional member? * What will happen when I pass object graphs, even when the last sentence warns against this? (e.g. marshaling into 1 big blob anyway, passing an error, etc.) * May a shareable member be, or contain a key?
Typo: 4rth paragraph: For the saMe of run-time efficiency -> For the saKe of run-time efficiency.....
if strongly assignable according to section 7.2.4 means that both types should be mutable, then why is the union in Table 15 (section 7.2.4.5, fifth bullet in 2nd column) talking about strong assignability for a T1 that is final or extensible? * Probably the definition for strongly typed is flawed, and should be about NON-mutable types. Generally speaking, the overall wording of the subject regarding strong assignability could is causing more confusion than it is clearing things up, and could use some big improvement. Lots of usecases regarding this subject are underspecified, for example: * If a type T1 is assignable from a type T2, and T1 has a non-optional member that is not represented in T2, it takes the default (non-configurable) default. How can I see the difference between a T1 with a member, that happens to be the default, and a T1 without that member? Since 0 is a very common value, it does not seems like a good candidate for default in this case.
In section 7.3.1.3.1 is is stated that when explicitly assigning memberID's to some attributes (but not to all attributes), that:
"In such cases, implicit values are assigned in a progression starting from the most-recently specified ID (or an implicit value of zero for the first constant, if there is no previous specified value) and adding one with each successive member."
This algorithm could result in the same memberId being assigned multiple times. Consider the following example:
struct A {
long x; //@id 2
long y; //@id 1
long z;
};Is it allowed to have a parent and a child struct share an attribute with the same name? * In most OO-languages this is allowed. * However, in scenario's like type-refactoring this will cause huge problems. We should clearly specify whether or not this is allowed, and when allowed we should clearly describe the consequences.
Section 7.3.4.1 specifies that a TypeObject can include just a single TypeLibrary while in section 7.3.4.1.1 it is claimed that a TypeObject can recursively contain other TypeLibraries. Of course this is confusing: which is it? Also does a typeID need to be globally unique or just in the TypeLibrary in which it is contained? Finally, and even more important, since the TypeObject may recursively refer to other (existing) types by their typeID, it is difficult to communicate the meta-data to a node that has no a-priori knowledge about it. The current TypeObject representation is compact, but only able to check whether two existing representations are compatible. It can't be used to drive meta-data based tooling a logger or a service that connects the DDS to a database.
In section 7.3.4.1.2 it is specified how to calculate the type ID for a given type. However, this algorithm heavily depends on the Type layout presented in Appendix B, which is not further explained. I have lots of questions about this algorithm, and am wondering if alternative mechanisms should not be considered instead. 1) Where does the hash that identifies the typeID of a constucted type come from? It states that it comes from the Big Endian CDR respresentation of the type, which is an IDL representation of the model specified in Appendix B. However, this data model is not further explained, and far from mature and orthogonal. It looks like we created a pretty ad-hoc type system rather than deriving one from a well-designed meta-model with a minimal set of powerful transformation primitives. There is a lot of existing documentation on how to set up a proper type-system. I suggest we consult some best-practices instead of re-inventing the wheel here. 2)The basis of the TypeObject consists of 2 fields, each having their own sequence. How the 2 sequences correlate is not further explained. The only thing that is explained in section 7.6.2.2 is that the the_type member of the TypeObject contains all types associated with the corresponding entity (1 for reader/writer, more for topic). I think it would be better to take this sequence outside TypeObject and give Topic a sequence of TypeObjects instead.
By clearly stating that a shared member must map onto a plain pointer, not a _var type or other smart pointer you are breaking the safety mechanisms that the C++ struct had inherently built into it, since on destruction or re-assignment the shared pointer may now leak away. The whole point of using _var types or other smart types was to prevent this from happening. I see no could reason why to make this one exception for shared pointers, which will make it much harder to predict the struct's behaviour.
Section 7.5.1.3.1 is referring to a C-mapping defined above. However, no C-mapping is mentioned so far, or it should refer to section 7.5.1.3.3 Section 7.5.1.3.3 seems to suggest the C-mapping should be done as in section 7.4.1.1.4, which is a sequence of name-value pair structs. I can't imagine that this is a serious mapping proposal, but if it is is should be clearly specified as such
Section 7.6.1 states that every component only uses 1 representation of a topic type. Some generic services (e.g. durability service or a logger) might discover a topic from another node but will still be able to handle all representations of it, without ever having type specific knowledge hardcoded into them.
Using a QosPolicy like DataRepresentationQosPolicy is breaking the abstraction between application and transport. This is fine if the application is managing its own transport, but not if the transport is implemented by some external service. We see no reason why this policy should be implemented as part of the XTypes specification as cleary it has no relationship to type extensibility.
The builtin topics have 2 ways to identify the type to which they apply: a string called type_name and a TypeObject alled type. The string can only relate to 1 type, while the TypeObject could refer to more than 1 type. If the type_name is not uniquely identifying a type, then what is the use of having a type_name in the builtin topics for Reader and Writer? The topic_name already refers to a DCPSTopic sample that has a similar type_name. Furthermore, in the spec it is assumed that Readers/Writers just make the TypeObject refer to just 1 type, while the Topic could make it refer to more than one. This is not orthogonal, so wouldn't it be better to make a TypeObject refer to 1 type and give the DCPSTopic a sequence of TypeObjects instead?
What if 2 topics have the same type, but different Qos? Would that still trigger an INCONSISTENT_TOPIC status or not? The spec does not say anything about this.
Section 7.6.3.2 specifies that lookup_topicdescription returns 1 matching representation. On multiple matches, an arbitrary representation is returned. This is not helpful in any way for an application trying to access a certain representation. Either its signature should be changed to return a sequence of topic representations, or it should cyclically go over each representation and return 1 at a time, so that subsequent invocations may return different representations.
Builtin topics are not backward compatible with the DDS1.2 spec (not even according to the rules of the Extensible types spec itself). As an example, the BuiltinTopicKey_t array has been extended from 3 elements to 4 elements. This breaks compatibility with respect to non-xTypes compliant versions of a DDS product, and it is not cleared up why the keyfield suddenly required this extra element.
Checked with Xerces, the XSD file has many errors which come from the lack of use of namespace. Lines: 37, 57, 60, 108, 111, 114, 136, 139, 143, 146, 241, 248, 267, 270, 277, 294, 370, 373, 435, 439, 442, 445, 448, 465, 495, 520, 523, 557, 560, 578, 581, 640 Xerces error (for the first one: "filename"): "E [Xerces] src-resolve.4.1: Error resolving component 'fileName'. It was detected that 'fileName' has no namespace, but components with no target namespace are not referenceable from schema document 'http://www.omg.org/spec/DDS-XTypes/20120202/dds-xtypes_type_definition.xsd'. If 'fileName' is intended to have a namespace, perhaps a prefix needs to be provided. If it is intended that 'fileName' has no namespace, then an 'import' without a "namespace" attribute should be added to 'http://www.omg.org/spec/DDS-XTypes/20120202/dds-xtypes_type_definition.xsd'." W3C reference: http://www.w3.org/TR/xmlschema11-1/#src-resolve