[Priority Feedback] More issues with <redefine/>

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.

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

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.

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

[4] READABILITY

Here is a sample from Part 1,
http://www.w3.org/TR/2000/CR-xmlschema-1-20001024/#modify-schema

"The schema components (that is {type definitions} {attribute declarations},
{element declarations}, {attribute group definitions}, {model group
definitions}, {notation declarations}) of a schema corresponding to a schema
element information item with one or more redefine element information items
must include not only definitions or declarations corresponding to the
appropriate members of its [children], but also, for each of those redefine
element information items for which clause 1.1 above obtains successfully,
with the exception of those components explicitly redefined, as described in
Individual Component Redefinition (§6.2.2) below, a set of components
identical to all the schema components of I (if clause 1.2.2 above obtains),
or identical in all respects except their {target namespace}, which is that
of the includeing schema (if clause 1.2.1 above obtains)."

I find this sentence difficult to parse. The above fragment is ONE SENTENCE
with 123 WORDS. Rudolf Flesch uses a method to measure readability based on
words per sentence. It is,

Words per sentence - Readability

7 - Plain English
12 - Fairly Difficult
30 - Very Difficult
37 - Practically Unreadable
123 - ???

Proposed Solution

I request the WG to remove 'including modified component definitions' and
consider this powerful feature for XML Schema 2.0 or later.

Thank you.

Asir S Vedamuthu

webMethods, Inc.
703-460-2513 or asirv@webmethods.com
http://www.webmethods.com/

Received on Tuesday, 19 December 2000 15:49:12 UTC