[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: ISSUE 181: Nested normative statements in 7.4.2
Hi Guys, I promised to come up with wording for the last sentence, and here it is. But actually, I would prefer to simply leave the sentence out, since there is no point in calling attention to the cases we don’t handle. If a ComplexType has content with two elements that have the same local name and the same targetNamespace, whether through declaration, extension, substitution, groups, or other means, the duplication MUST BE handled with these rules: · The ComplexType becomes a sequenced type, as if sdox:sequence="true" was declared. · A single property is used for all the elements with the same local name and the same targetNamespace. If the content model allows more than 1 instance of the element, then isMany=true. If, however, the elements are mutually exclusive (for example, they are single valued and on two sides of a xsd:choice group), then isMany=false. [COR07040201] Defining types as extensions of previously defined types potentially creates conflicts between the new type and the base type. For instance, if the property was defined in the base type as being single-valued, but has to be multi-valued in the derived type. Results are undefined in such cases. From: Barack, Ron [mailto:ron.barack@sap.com] If we resolve to remove the compliance points, we should also remove the reference to this section currently in section 7.4 Ron From: Barack, Ron Hi Bryan, I have some reservations about the second bullet, but I think the final statement is really broken. Use case is that we have a complex non-sequenced, and one of the properties in the sequence, say ‘a’ has maxOccurs=1. Let’s imagine that we load the schema, and instanciate a few DataObjects from it. OK, now we load a second schema. In this schema is a second type that extends the first type, but adds and additional “a” element. Might sound bizarre, but this is allowed and well defined in XML. But of course, it comflicts with SDO’s notion of a property. We want to deal with this case as a multivalued property, but we can’t, because the base type has already been created, and SDO can’t redefine the property. I don’t think we want to provide for properties being changed… it’s particularly troubling because metadata can be shared between threads. Also, I’m not at all sure why we want to change the base type to sequenced? AFAIK, a child of a non-sequenced type can be sequenced, but not the other way around. Maybe this MUST is intended for the provider of the schema. That is, I think we are saying (or should be saying) that we don’t handle this “corner case”. I would like to just get rid of the last sentence, and enhance the last bullet point with: This potentially creates a conflict with the base type, namely, if the property was defined there as being single-valued. Results are undefined in such cases. Best Regards, Ron From: Barack, Ron [mailto:ron.barack@sap.com] http://www.osoa.org/jira/browse/SDO-181 From: Bryan Aupperle [mailto:aupperle@us.ibm.com] Proposed restructure: If a ComplexType has content with two elements that have the same local name and the same targetNamespace, whether through declaration, extension, substitution, groups, or other means, the duplication MUST BE handled with these rules: · The ComplexType becomes a sequenced type, as if sdox:sequence="true" was declared. · A single property is used for all the elements with the same local name and the same targetNamespace. If the content model allows more than 1 instance of the element, then isMany=true. If, however, the elements are mutually exclusive (for example, they are single valued and on two sides of a xsd:choice group), then isMany=false. [COR07040201] If schema extension is used, the base type MAY be modified with sdox:sequence="true". [COR07040202] A Property in the extended base type derived from elements with name conflicts introduced in extensions MUST have many=true. [COR07040203]
If a ComplexType has content with two elements that have the same local name and the same targetNamespace, whether through declaration, extension, substitution, groups, or other means, the duplication MUST BE handled as follows [COR07040201]: · The ComplexType becomes a sequenced type, as if sdox:sequence="true" was declared. · A single property is used for all the elements with the same local name and the same targetNamespace. If the content model allows more than 1 instance of the element, then isMany=true. If, however, the elements are mutually exclusive (for example, they are single valued and on two sides of a xsd:choice group), then isMany=false. · If schema extension is used, the base type MAY be modified with sdox:sequence="true". Elements with name conflicts introduced in extensions require that the property in the extended base type MUST BE made many=true. [COR07040202]
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]