[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 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]