Issue 7278: Semantics of IDL generated from Deployment & Configuration Specification ExternalReferneceEndpoint (deployment-ftf) Source: Vanderbilt University (Mr. Krishnakumar Balasubramanian, kitty@dre.vanderbilt.edu) Nature: Uncategorized Issue Severity: Summary: see the following definition in the IDL generated from the Target Data Model using UML Profile for CORBA, and have some issues with semantics when interpreting the following generated IDL mapping from the model: struct SharedResource { string name; ::CORBA::StringSeq resourceType; ::CORBA::ULongSeq nodeRef; SatisfierProperties property; }; typedef sequence < SharedResource > SharedResources; struct Resource { string name; ::CORBA::StringSeq resourceType; SatisfierProperties property; }; typedef sequence < Resource > Resources; struct Node { string name; string label; ::CORBA::ULongSeq sharedResourceRef; ::CORBA::ULongSeq connectionRef; Resources resource; }; struct Domain { string UUID; string label; SharedResources sharedResource; Nodes node; Interconnects interconnect; Bridges bridge; }; The idea of the above IDL is to represent the following semantics: A Domain is composed of Nodes (among other things). A Domain can also contain a list of the resources that are shared among the different nodes in the domain. There is also an association between the Nodes of the domain and the SharedResources in a domain. Basically, the nodes of the domain contain a list of the resources that they share with other nodes, and the each shared resource keep track of the nodes that share it. Please refer to Fig 6-4 Target Data Model Overview, in the document: http://www.omg.org/cgi-bin/doc?ptc/2004-03-10 Ideally one should be able to represent this in IDL like this: struct Node; typedef Sequence<Node> Nodes; struct SharedResource { string name; ::CORBA::StringSeq resourceType; Nodes nodeRef; SatisfierProperties property; }; except that this is invalid IDL. The alternative mapping that is generated doesn't seem to make sense. What should I fill in as values for the ::CORBA::ULongSeq in struct SharedResource? Why did it get mapped to an CORBA::ULongSeq? Is it intended that these unsigned longs will refer to the *gasp* pointers of the actual nodes in my parsed DOM tree with Domain as root? If so, it will not work with 64-bit machines. How is one supposed to refer a IDL struct member i.e, node inside a Domain using unsigned long? The only identifier that is unique among all nodes in a Domain is it's name. But unsigned long just doesn't make sense to me. The above illegal IDL definition which directly includes Nodes after just forward declaring node would work if Node was mapped to a valuetype. But I don't know if that is a feasible solution. Any clarifications on this would be really helpful. Resolution: Revised Text: Actions taken: April 30, 2000: received issue May 9, 2005: closed issue Discussion: During the meetings and telephone conferences of the previous FTF it has been agreed that this issue is to be closed without change since it is due to misunderstanding. The values for the ::CORBA::ULongSeq in struct SharedResource is the index of the referenced element in its container, i.e., in the case, it's the index of the target Node in the Domain (i.e., the index into the Domain's "node" list). The magic here is explained in the second paragraph of section 9.4.1: To void redundancy and circular graphs, non-composite associations between classes with a common owner are expressed by an ordinal attribute at the source (navigating) end, with the name of the attribute being the role name plus the suffix "Ref," and the type "unsigned long." The value of this attribute is the index of the target element in its container, with the first element being 0 (zero). To enable the usage of an index, the composition of the target element in its container is wualified with the "ordered" constraint. Note that this rule also applies to a number of other associations, e.g., the "instance" reference in the SubcomponentPortEndpoint class. Disposition: Closed, no change End of Annotations:===== te: Fri, 30 Apr 2004 18:45:35 -0500 From: Krishnakumar B To: issues@omg.org Subject: Semantics of IDL generated from Deployment & Configuration Specification X-Mailer: VM 7.18 under Emacs 21.3.1 Hi, I see the following definition in the IDL generated from the Target Data Model using UML Profile for CORBA, and have some issues with semantics when interpreting the following generated IDL mapping from the model: struct SharedResource { string name; ::CORBA::StringSeq resourceType; ::CORBA::ULongSeq nodeRef; SatisfierProperties property; }; typedef sequence < SharedResource > SharedResources; struct Resource { string name; ::CORBA::StringSeq resourceType; SatisfierProperties property; }; typedef sequence < Resource > Resources; struct Node { string name; string label; ::CORBA::ULongSeq sharedResourceRef; ::CORBA::ULongSeq connectionRef; Resources resource; }; struct Domain { string UUID; string label; SharedResources sharedResource; Nodes node; Interconnects interconnect; Bridges bridge; }; The idea of the above IDL is to represent the following semantics: A Domain is composed of Nodes (among other things). A Domain can also contain a list of the resources that are shared among the different nodes in the domain. There is also an association between the Nodes of the domain and the SharedResources in a domain. Basically, the nodes of the domain contain a list of the resources that they share with other nodes, and the each shared resource keep track of the nodes that share it. Please refer to Fig 6-4 Target Data Model Overview, in the document: http://www.omg.org/cgi-bin/doc?ptc/2004-03-10 Ideally one should be able to represent this in IDL like this: struct Node; typedef Sequence Nodes; struct SharedResource { string name; ::CORBA::StringSeq resourceType; Nodes nodeRef; SatisfierProperties property; }; except that this is invalid IDL. The alternative mapping that is generated doesn't seem to make sense. What should I fill in as values for the ::CORBA::ULongSeq in struct SharedResource? Why did it get mapped to an CORBA::ULongSeq? Is it intended that these unsigned longs will refer to the *gasp* pointers of the actual nodes in my parsed DOM tree with Domain as root? If so, it will not work with 64-bit machines. How is one supposed to refer a IDL struct member i.e, node inside a Domain using unsigned long? The only identifier that is unique among all nodes in a Domain is it's name. But unsigned long just doesn't make sense to me. The above illegal IDL definition which directly includes Nodes after just forward declaring node would work if Node was mapped to a valuetype. But I don't know if that is a feasible solution. Any clarifications on this would be really helpful. Subject: Re: issue 7278 -- Deployment FTF issue Date: Sun, 9 May 2004 13:02:42 -0400 Thread-Topic: issue 7278 -- Deployment FTF issue Thread-Index: AcQ1k52ZYyjIVPOCRsCtipu2BF/dbAAUG0Qg From: "Pilhofer, Frank" To: "Krishnakumar B" Cc: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i49H3bFh015570 > From: Krishnakumar B [mailto:kitty@dre.vanderbilt.edu] > On Friday, 7 May 2004, Pilhofer, Frank wrote: > > the value is the index of the referenced element in its container, i.e., > > in the case, it's the index of the target Node in the Domain (i.e., the > > index into the Domain's "node" list). > > > > Doh! My bad. Thanks for the clarification. > > But I think the semantics of the XML schema generated for a reference > doesn't match either the semantics given by the model, or that expressed in > the IDL. I was always curious as to why the proxying of elements through > HREF and IDREF via xmi:ObjectAttribs, was allowed for such references. > > For example, the following definition of SharedResource, > [...] > allows for a Node to be defined inside a SharedResource, > > > > .... > .... > > > > which is semantically invalid (???). I wonder if this is a > known problem... > Hi Kitty, the intention is that elements are defined in one place only, as part of the element's container (in this case, container for a Node element is the Domain) and referenced by proxy elsewhere, e.g., ... ... ... The plain schema is not strict enough in this respect and allows for invalid situations such as the one that you describe. We thus added more restrictive text to section 9.5.8 (as updated by issue 6383), which says, "Composition associations in UML express that the class at the composite end (the containing class) owns and contains the class at the part end (the contained class). It is typical, in XML documents, for instances of contained classes to be embedded within the instance of the containing class. However, it is also possible to store contained instances by themselfes in a separate file [...] "For non-composite associations between classes with a common owner, the Subject: Re: issue 7278 -- Deployment FTF issue Date: Sun, 9 May 2004 13:32:06 -0400 Thread-Topic: issue 7278 -- Deployment FTF issue Thread-Index: AcQ1mNIZGmIhmO6zSkOZ8r1JxZcDMwATwvgg From: "Pilhofer, Frank" To: "Krishnakumar B" Cc: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i49HWpFh015836 > -----Original Message----- > From: Krishnakumar B [mailto:kitty@dre.vanderbilt.edu] > > In the same vein, the existing schema also allows for stuff like the > following to be silently accepted by the XML Schema Validator (actually the > validator is not at fault, as the following is semantically invalid and not > syntactically valid): > > > > > 154cf3cd-1770-4e92-b19b-8c2c921fea38 > > > > primaryArtifact > <============= > > c7264c15-d373-4d01-84ee-d37536599240 > [...] > > > > > > The above file defines an Implementation Artifact first as a proxy > (href="GPS.iad") and then proceeds to define it locally too. This is valid > XML according to the schema. In such a case, which one takes precedence? > Who makes this decision? How will any automatically generated XML parser > code handle this? Is there any behaviour mandated by the specification for > dealing with such situations? Any thoughts on this welcome. > Yes, the XML schema allows that. However, there is text in the XMI specification that disallows such elements. XMI 2.0 (OMG document no. formal/03-05-02, section 1.10.1 on page 1-21) says, "Elements act as a union, where they are either a definition or a proxy. Proxies use the LinkAttribs attribute group to define the link, and contain no nested elements." I agree that the schema should be stronger in this respect. However, the XMI FTF members do not concur. When I filed a related issue (5950), the proposed suggestion was to not use proxies at all, see http://www.omg.org/archives/mof2xmi-ftf/msg00026.html Our parser considers it an error if a proxy element contains any content. > > Similarly defining every element at the top level in Deployment.xsd (using > ) allows generation of > descriptors, say foo.ccd with semantically invalid content, for example a > Domain. It seems that defining only top-level elements like > ComponentInterfaceDescription, Domain, ComponentImplementationDescription, > Component to to appear at the top-level is needed. Any thoughts on this too > welcome. > A parser should notice that soon enough ;) Allowing all elements to appear at the top-level of an XML document does have its benefits. Who are we to dictate file granularity? If someone wants to place, for example, properties in a separate file, so be it. I suppose we could slice up the model and eventually generate multiple schemas, but I don't think there's enough benefit to that. IMHO, a descriptor that contains semantically wrong data (i.e., content that disagrees with its intended use, such as a component package referencing Domain data) is no different from a descriptor that contains nonsensical data -- which no validator can protect against. Frank Subject: Re: issue 7278 -- Deployment FTF issue Date: Fri, 7 May 2004 15:49:04 -0400 Thread-Topic: issue 7278 -- Deployment FTF issue Thread-Index: AcQ0amRGl7f+UTa7SOiP1tKU8oVOpwAAHqeg From: "Pilhofer, Frank" To: Cc: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i47JnaFh020242 > > The alternative mapping that is generated > doesn't seem to make sense. What should I fill in as values for the > ::CORBA::ULongSeq in struct SharedResource? Why did it get mapped to an > CORBA::ULongSeq? Is it intended that these unsigned longs will refer to the > *gasp* pointers of the actual nodes in my parsed DOM tree with Domain as > root? > Hello Kitty, the value is the index of the referenced element in its container, i.e., in the case, it's the index of the target Node in the Domain (i.e., the index into the Domain's "node" list). The magic here is explained in the second paragraph of section 9.4.1: To void redundancy and circular graphs, non-composite associations between classes with a common owner are expressed by an ordinal attribute at the source (navigating) end, with the name of the attribute being the role name plus the suffix "Ref," and the type "unsigned long." The value of this attribute is the index of the target element in its container, with the first element being 0 (zero). To enable the usage of an index, the composition of the target element in its container is wualified with the "ordered" constraint. Note that this rule also applies to a number of other associations, e.g., the "instance" reference in the SubcomponentPortEndpoint class. -kitty. Date: Mon, 10 May 2004 09:12:55 -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.6) Gecko/20040113 X-Accept-Language: en,pdf To: "Pilhofer, Frank" CC: Krishnakumar B , deployment-ftf@omg.org Subject: Re: issue 7278 -- Deployment FTF issue Perhaps we could put into the document a simple bulleted list of checks that any parser may want to do in addition to what the schema allows, to make up for the current deficiencies of the XMI spec. Jim Pilhofer, Frank wrote: From: Krishnakumar B [mailto:kitty@dre.vanderbilt.edu] On Friday, 7 May 2004, Pilhofer, Frank wrote: the value is the index of the referenced element in its container, i.e., in the case, it's the index of the target Node in the Domain (i.e., the index into the Domain's "node" list). Doh! My bad. Thanks for the clarification. But I think the semantics of the XML schema generated for a reference doesn't match either the semantics given by the model, or that expressed in the IDL. I was always curious as to why the proxying of elements through HREF and IDREF via xmi:ObjectAttribs, was allowed for such references. For example, the following definition of SharedResource, [...] allows for a Node to be defined inside a SharedResource, .... .... which is semantically invalid (???). I wonder if this is a known problem... Hi Kitty, the intention is that elements are defined in one place only, as part of the element's container (in this case, container for a Node element is the Domain) and referenced by proxy elsewhere, e.g., ... ... ... The plain schema is not strict enough in this respect and allows for invalid situations such as the one that you describe. We thus added more restrictive text to section 9.5.8 (as updated by issue 6383), which says, "Composition associations in UML express that the class at the composite end (the containing class) owns and contains the class at the part end (the contained class). It is typical, in XML documents, for instances of contained classes to be embedded within the instance of the containing class. However, it is also possible to store contained instances by themselfes in a separate file [...] "For non-composite associations between classes with a common owner, the definition of the class at the source end of the association must contain a proxy linking to the element at the target end of the association. [...]" Frank