- From: Henry S. Thompson <ht@cogsci.ed.ac.uk>
- Date: 20 Dec 2000 16:22:26 +0000
- To: "Asirv" <Asirv@webmethods.com>
- Cc: www-xml-schema-comments@w3.org, "Ningang chen" <nchen@webmethods.com>
"Asirv" <Asirv@webmethods.com> writes:
> YES, 'including modified component definitions' is a powerful feature. But,
> it raises several issues. These are subtle and critical issues. I will
> attempt to describe them as clearly as possible. If they are not clear,
> please ask me questions.
>
> [1] NAMESPACE COERCION
>
> 'including modified component definitions' provides simple namespace
> coercion. Apologize, it is not simple but little complicated. This feature
> is based on the assumption that such included component definitions do not
> carry the namespace as an integral component. Hence, just coerce it. This is
> not true. I would like to illustrate this using two examples. Assumption:
> targetNamespace of the example schema document is absent and I picked up two
> random wild card fragments.
>
> <anyAttribute namespace="##other"/> --- A
>
> A maps to an attribute wild card with the following properties,
>
> {namespace constraint} - not and absent
> {process contents} - strict
>
> This component validates elements that are namespace qualified. If not, it
> is invalid.
>
> <anyAttribute namespace="##targetNamespace"/> --- B
>
> B maps to an attribute wild card with the following properties,
>
> {namespace constraint} - absent
> {process contents} - strict
>
> This component validates elements that are unqualified. If not, it is
> invalid.
>
> During namespace coercion, the targetNamespace of this example's
> corresponding schema information item (SII) is the targetNamespace of
> redefining SII. If this latter targetNamespace is present (namespace
> coercion happens), wild card components, A and B, produce undesired (or
> catastrophic) results. Because, these components were processed before
> redefinition.
Good point, but nothing to do with redefine.
> [2] IMPACT on ANONYMOUS TYPE DEF's {content type} whose BASE DEFINITIONS
> were redefined
>
> This can be best illustrated using an example. Sir, please pardon me if the
> syntax is incorrect.
>
> v1.xsd:
> <xs:complexType name="personName">
> <xs:sequence>
> <xs:element name="title" minOccurs="0"/>
> <xs:element name="forename" minOccurs="0" maxOccurs="unbounded"/>
> </xs:sequence>
> </xs:complexType>
>
> <xs:element name="addressee">
> <xs:complexType>
> <xs:complexContent>
> <xs:extension base="personName">
> <xs:sequence>
> <xs:element name="surname" minOccurs="1"/>
> </xs:sequence>
> </xs:extension>
> </xs:complexType>
> </xs:complexContent>
> </xs:element>
>
> v2.xsd:
> <xs:redefine schemaLocation="v1.xsd">
> <xs:complexType name="personName">
> <xs:complexContent>
> <xs:extension base="personName">
> <xs:sequence>
> <xs:element name="generation" minOccurs="0"/>
> </xs:sequence>
> </xs:extension>
> </xs:complexContent>
> </xs:complexType>
> </xs:redefine>
>
> <xs:element name="author" type="personName"/>
>
> In the above example, before redefinition, addressee declaration component
> has the following content,
>
> <!ELEMENT addressee (title?, forename*, surname)>
>
> First, Part 1 does not say what happens to the anonymous complex type of
> addressee declaration component after redefinition. Intuitively, I would
> expect it to be,
>
> <!ELEMENT addressee (title?, forename*, generation?, surname)>
Yes, that's right. Same as what would happen if you simply edited
v1.xsd:personName to have a generation.
> Second, it is impossible (using the given mapping rules) to construct the
> above declaration component after redefinition. Because, the addresee
> declaration component, its anonymous complex type and {content type} were
> computed before redefinition.
No, the spec. is very clear that the semantics are as if the change
happened before any reference to the redefined type, i.e. the
semantics is as if the edit were done by hand.
> [3] UNDERSPECIFIED
>
> What is the surface syntax for redefining 'attributeGroup' and 'modelGroup'?
> Part 1 says something about this at the abstract level. But, I am unable to
> find anything that is concrete. Here is a snip,
>
> "1.4 Within the [children], each group must have exactly one group among
> its contents at some level the normalized value of whose ref [attribute]
> must be the same as the normalized value of its own name attribute plus
> target namespace;
> 1.5 Within the [children], each attributeGroup must have exactly one
> attributeGroup among its [children] the normalized value of whose ref
> [attribute] must be the same as the normalized value of its own name
> attribute plus target namespace;"
>
> How about a few examples?
> "name attribute plus target namespace" - how does namespace coercion impact
> this?
>
> I attempted to author an example,
>
> <attributeGroup name="specialAttrs">
> <attributeGroup name="specialAttrs"/> -- C
> <attributeGroup name="moreAttrs"/> -- D
> </attributeGroup>
>
> C refers an attributeGroup in the SII being redefined and D refers to an
> attributeGroup in ?? I am confused.
You mean
<attributeGroup name="specialAttrs">
<attributeGroup ref="specialAttrs"/> -- C
<attributeGroup ref="moreAttrs"/> -- D
</attributeGroup>
Normal namespace rules apply, so whatever the default NS declaration
in force is determines both the referents at C and D, and it better be
the targetNamespace or the redefine is broken.
> Proposed Solution
>
> I request the WG to remove 'including modified component definitions' and
> consider this powerful feature for XML Schema 2.0 or later.
I strongly oppose this, we need it and it's very easy to implement.
ht
--
Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
W3C Fellow 1999--2001, part-time member of W3C Team
2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
Fax: (44) 131 650-4587, e-mail: ht@cogsci.ed.ac.uk
URL: http://www.ltg.ed.ac.uk/~ht/
Received on Wednesday, 20 December 2000 11:22:29 UTC