Issue 7354: XML Schema of Deployment spec doesn't honour constraints present in model (deployment-rtf) Source: Vanderbilt University (Mr. Krishnakumar Balasubramanian, kitty(at)dre.vanderbilt.edu) Nature: Uncategorized Issue Severity: Summary: Hi, The Deployment & Configuration XML Schema defines a Property element like: <xsd:complexType name="Property"> <xsd:choice minOccurs="0" maxOccurs="unbounded"> <xsd:element name="name" type="xsd:string" /> <xsd:element name="value" type="Deployment:Any" /> <xsd:element ref="xmi:Extension" /> </xsd:choice> <xsd:attribute ref="xmi:id" use="optional" /> <xsd:attributeGroup ref="xmi:ObjectAttribs" /> </xsd:complexType> <xsd:element name="Property" type="Deployment:Property" /> This allows for the following invalid Property file to be passed silently by the XML Schema validator: <?xml version="1.0" encoding="UTF-8" standalone="no" ?> <Deployment:Property xmlns:Deployment="http://www.omg.org/Deployment" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.omg.org/Deployment Deployment.xsd"> <name>ORBSvcConf</name> <value> <type> <kind>tk_string</kind> </type> <value> <string>Foo</string> </value> </value> <value> <type> <kind>tk_short</kind> </type> <value> <long>123</long> </value> </value> </Deployment:Property> The model in 6.10.8 has a containment association with a cardinality one for value. The schema generated from that model doesn't match the semantics in the model. This is just an example. There are a lot of elements where the semantics imposed by the schema are different from what is described in the model. I am curious as to why this is allowed. It can be easily fixed by changing the schema to: <xsd:complexType name="Property"> <xsd:sequence minOccurs="0" maxOccurs="1"> <xsd:element name="name" type="xsd:string" /> <xsd:element name="value" type="Deployment:Any" /> <xsd:element ref="xmi:Extension" minOccurs="0" /> </xsd:sequence> <xsd:attribute ref="xmi:id" use="optional" /> <xsd:attributeGroup ref="xmi:ObjectAttribs" /> </xsd:complexType> <xsd:element name="Property" type="Deployment:Property" /> Resolution: Revised Text: Actions taken: May 13, 2004: received issue June 29, 2004: re-assigned to the MOF 2 XMI RTF December 10, 2009: re-assigned to the Deployment RTF (not chartered at this time) December 16, 2009: re-asigned to the deployment-rtf Discussion: During the meetings and telephone conferences of the RTF it has been agreed that this issue is to be transferred to the MOF2XMI RTF. The source of this problem (issue #5950) has already been submitted to the MOF2XMI FTF. They acknowledged the problem but decided to close it without change since it would be too much work for them. Now a related issue is popping up again. End of Annotations:===== te: Thu, 13 May 2004 19:41:49 -0500 From: Krishnakumar B To: issues@omg.org Subject: XML Schema of Deployment & Configuration specification doesn't honour constraints present in the model X-Mailer: VM 7.18 under Emacs 21.3.1 Hi, The Deployment & Configuration XML Schema defines a Property element like: This allows for the following invalid Property file to be passed silently by the XML Schema validator: ORBSvcConf tk_string Foo tk_short 123 The model in 6.10.8 has a containment association with a cardinality one for value. The schema generated from that model doesn't match the semantics in the model. This is just an example. There are a lot of elements where the semantics imposed by the schema are different from what is described in the model. I am curious as to why this is allowed. It can be easily fixed by changing the schema to: Date: Tue, 18 May 2004 19:59:45 -0500 From: Krishnakumar B To: "Pilhofer, Frank" Cc: , Subject: RE: issue 7354 -- Deployment FTF issue: XML Schema doesn't honour constraints present in model X-Mailer: VM 7.18 under Emacs 21.3.1 On Tuesday, 18 May 2004, Pilhofer, Frank wrote: > > Kitty, > > this is a side effect of using the XMI schema production rules, as > defined by XMI 2.0 (formal/03-05-02, chapter 2). > > The rules allow to generate a stricter schema by setting the > enforceMinimumMultiplicity and enforceMaximumMultiplicity tags, > resulting in an "xsd:sequence" element like you are describing. > > However, doing so breaks the ability to use cross-references by > proxy. But the complex type definition that I had defined should allow for proxies: I don't see why proxies shouldn't be allowed if the schema is defined like the above. In fact, I just tested it and it validates with Xerces. > Because we wanted to allow for arbitrary file segmentation, we chose to > allow proxys at the expense of a weaker schema that is not able to > validate element multiplicities according to the model. But you do realize the result of this? One has to add checks all over the place (over and above what is done by the XML validator). There are likely to be bugs in these checks, as these are likely to be added by people who might not really understand the nuances of XML. Considering that XML is the basis of information exchange, this *troubles me*. One of the main motivations for storing the meta-data in XML is that one gets out-of-the box abstract syntax validation capability. But if my information model is weak (though in this case the model is fine but the representation/transformation is weak), then I am starting with a weak foundation. > Curiously, the MOF2XMI FTF considers this a feature, not a bug; see the > discussion and resolution of issue 5950, > http://www.omg.org/archives/mof2xmi-ftf/msg00026.html Maybe, but it seems to me that this argument is based on the assumption that 1. XMI is *the* basis for making these decisions. 2. Since XMI can't do it we will make our information model weak, and force implementations to add unnecessary (potentially buggy) checks, to compensate for the weak information model. This definitely doesn't look like a easy road to take; if at all one takes it. Already we have the possibility of both proxies and elements appearing simultaneously, because XMI doesn't prohibit them. This just adds to it. Anyway thanks a lot for your inputs. Looks like a couple of XSLT scripts are needed for generating our implementation's schema from the Deployment's schema. IMHO, there doesn't seem to be any value addition in following the generated XSD schema, if it's weak. I just hope the XML Schema is not a compliance point (or whatever is the equivalent). -kitty. Date: Wed, 19 May 2004 08:46:22 -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: deployment-ftf@omg.org, Krishnakumar B Subject: Re: issue 7354 -- Deployment FTF issue: XML Schema doesn't honour constraints present in model Perhaps a resolution to this issue would be to have a paragraph noting extra post-parsing validation that could be done, but that is not done at the schema level due to the issues you describe. Jim Pilhofer, Frank wrote: From: Krishnakumar B The Deployment & Configuration XML Schema defines a Property element like: This allows for invalid Property files with multiple names and/or values to be passed silently by the XML Schema validator, when the model only allows for exactly one name and value. The model in 6.10.8 has a containment association with a cardinality one for value. The schema generated from that model doesn't match the semantics in the model. I am curious as to why this is allowed. It can be easily fixed by changing the schema. Kitty, this is a side effect of using the XMI schema production rules, as defined by XMI 2.0 (formal/03-05-02, chapter 2). The rules allow to generate a stricter schema by setting the enforceMinimumMultiplicity and enforceMaximumMultiplicity tags, resulting in an "xsd:sequence" element like you are describing. However, doing so breaks the ability to use cross-references by proxy. Because we wanted to allow for arbitrary file segmentation, we chose to allow proxys at the expense of a weaker schema that is not able to validate element multiplicities according to the model. Curiously, the MOF2XMI FTF considers this a feature, not a bug; see the discussion and resolution of issue 5950, http://www.omg.org/archives/mof2xmi-ftf/msg00026.html Frank Subject: RE: issue 7354 -- Deployment FTF issue: XML Schema doesn't honour constraints present in model Date: Wed, 19 May 2004 09:21:58 -0400 Thread-Topic: issue 7354 -- Deployment FTF issue: XML Schema doesn't honour constraints present in model Thread-Index: AcQ9PJbUfcZ9XY0TTJWb40eB/RPB4QAY/JKg From: "Pilhofer, Frank" To: "Krishnakumar B" Cc: , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i4JDNuun007779 From: Krishnakumar B [mailto:kitty@dre.vanderbilt.edu] > > But the complex type definition that I had defined should allow for > proxies: > Yes. But that is beside the point. > > Maybe, but it seems to me that this argument is based on the > assumption that > > 1. XMI is *the* basis for making these decisions. > 2. Since XMI can't do it we will make our information model weak, and force > implementations to add unnecessary (potentially buggy) checks, to > compensate for the weak information model. > While designing the specification, we decided not to reinvent the wheel. The XMI Schema Production rule set generates a schema that works pretty well. It does not restrict our information model, it defines a powerful cross-linking capability, it is model-based and can be automatically generated from the model, and it existed. Compared with a hand-crafted schema, or with our own set of rules for a model- generated schema, that is so much better. Maybe we could do better, but not without spending significant effort that we should better devote to the core of our specification. I am not arguing that XMI's deficiencies or weaknesses should be ignored. I would like to see a stronger schema being defined by XMI's rule set, and have filed several issues to that effect. I'm just arguing that issues should be addressed by the proper authority, and that is the (MOF2) XMI FTF. So we should be more active in making that FTF see our point of view. Stephen, what would it take for you to reconsider the resolution to this particular issue, considering that we need both proxies and "multiplicity enforcement" in the same document? > > Anyway thanks a lot for your inputs. Looks like a couple of XSLT scripts > are needed for generating our implementation's schema from the Deployment's > schema. IMHO, there doesn't seem to be any value addition in following the > generated XSD schema, if it's weak. I just hope the XML Schema is not a > compliance point (or whatever is the equivalent). > What we (at Mercury), as a workaround, generate an XML parser not from the schema, but from the original model. We can thus generate additional checks, based on the DOM tree, to verify multiplicity constraints. -kitty.