W3C home > Mailing lists > Public > xmlschema-dev@w3.org > January 2002

RE: Semantics of elementFormDefault / Form

From: Slein, Judith A <JSlein@crt.xerox.com>
Date: Wed, 2 Jan 2002 11:28:49 -0500
Message-ID: <D753E5FC52E98943AC5C56E4446F89843F4EE2@crte147.wc.eso.mc.xerox.com>
To: "'Jeni Tennison'" <jeni@jenitennison.com>, xmlschema-dev@w3.org
Cc: Priscilla Walmsley <priscilla@walmsley.com>, "Slein, Judith A" <JSlein@crt.xerox.com>, "Kurian, Binil" <BKurian@crt.xerox.com>, "Sembower, Neil R" <NSembower@crt.xerox.com>, "'Graham Mann'" <gmann@adobe.com>
Thanks to Jeni and Priscilla for their comments on these questions about
namespaces.  It's disappointing that there seems to be no definitive answer
to whether an element that is in no namespace should be treated as in
##other or not.

Here is another confusing case (for which Xerces and IBM Schema Quality
Checker give different results):  From my namespace I reference a group that
was defined in another namespace. The namespace where the group is defined
has elementFormDefault="qualified".  To which namespace do the elements
contained in the group belong when used in their new context?  To complicate
the situation further, the group being referenced contains a wildcard
declaration with ##other.

Here is a definition in my namespace:

<schema
targetNamespace="http://www.xerox.com/XMLSchemas/Services/EmailDistMsgLayer"
xmlns:em="http://www.xerox.com/XMLSchemas/Services/EmailDistMsgLayer"
xmlns:jdf="http://www.CIP4.org/JDFSchema_1"
xmlns="http://www.w3.org/2001/XMLSchema">
  <import namespace="http://www.CIP4.org/JDFSchema_1"
schemaLocation="JDF.xsd"/>
. . .
  <complexType name="EmailDistribution">
    <complexContent>
      <extension base="jdf:JDFBaseType_">
        <sequence minOccurs="0" maxOccurs="unbounded">
          <group ref="jdf:JDFChildElements_"/>
          <element name="ResourceLinkPool" type="em:EmailDistResLinkPool_"
minOccurs="0"/>
        </sequence>
        <attribute name="Type" type="NMTOKEN" use="required"/>
      </extension>
    </complexContent>
  </complexType>
</schema>

The group JDFChildElements_ is defined in another namespace:

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:jdf="http://www.CIP4.org/JDFSchema_1" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
targetNamespace="http://www.CIP4.org/JDFSchema_1" 
elementFormDefault="qualified" attributeFormDefault="unqualified">

<xsd:group name="GenericElements">
	<xsd:sequence>
		<xsd:element ref="jdf:Comment" minOccurs="0"/>
		<xsd:any namespace="##other" processContents="lax"
minOccurs="0"/>
	</xsd:sequence>
</xsd:group>

<xsd:group name="JDFChildElements_">
	<xsd:sequence>
		<xsd:group ref="jdf:GenericElements" minOccurs="0"/>
		<xsd:element name="AncestorPool" type="jdf:AncestorPool_"
minOccurs="0"/>
		<xsd:element name="AuditPool" type="jdf:AuditPool_"
minOccurs="0"/>
		<xsd:element name="CustomerInfo" type="jdf:CustomerInfo_"
minOccurs="0"/>
		<xsd:element name="NodeInfo" type="jdf:NodeInfo_"
minOccurs="0"/>
		<xsd:element name="ResourcePool" type="jdf:ResourcePool_"
minOccurs="0"/>
		<xsd:element name="StatusPool" type="jdf:StatusPool_"
minOccurs="0"/>
		<xsd:element ref="jdf:JDF" minOccurs="0"/>
	</xsd:sequence>
</xsd:group>

</xsd:schema>

Now whether there should be ambiguous content model errors here depends
partly on the resolution of the earlier issue about no-namespace elements
and ##other, and partly on which namespace the elements in
jdf:JDFChildElements_ belong to when they occur inside an element of type
em:EmailDistribution (and where the wildcard in jdf:JDFChildElements_ is
understood as having been declared).

Thanks for any help you can provide in clarifying this case.

--Judy

-----Original Message-----
From: Jeni Tennison [mailto:jeni@jenitennison.com]
Sent: Wednesday, December 19, 2001 6:41 AM
To: xmlschema-dev@w3.org
Cc: Priscilla Walmsley; 'Slein, Judith A'; 'Kurian, Binil'; 'Sembower,
Neil R'; 'Graham Mann'
Subject: Re: Semantics of elementFormDefault / Form


Priscilla Walmsley wrote:
> With namespace="##other", you should _never_ get an ambiguous
> content model error, because ##other means that the elements
> matching the wildcard _must_ be in a namespace. Since unqualified
> local elements must _not_ be in a namespace, there is no ambiguity.

Hmm... I think that there's a contradiction in the Rec.

In the Rec it says that when namespace="##other", the {namespace
constraint} of the wildcard schema component is:

 "a pair of not and the actual value of the targetNamespace attribute
  of the schema ancestor element information item if present,
  otherwise absent."

In the description of the {namespace constraint} of the wildcard
schema component, it says that the {namespace constraint} provides for
validation of element items that:

 "(not and a namespace name) have any namespace other than the
  specified namespace name, or are not namespace qualified;"
                            ==============================

Which I think implies that wildcards with namespace=##other do match
unqualified elements.

But later on in "Validation Rule: Wildcard allows Namespace Name" it
says:

  For a value which is either a namespace name or ·absent· to be
  ·valid· with respect to a wildcard constraint (the value of a
  {namespace constraint}) one of the following must be true:

  2 All of the following must be true:
  2.1 The constraint is a pair of not and a namespace name or
      ·absent· ([Definition:] call this the namespace test).
  2.2 The value must not be identical to the ·namespace test·.
  2.3 The value must not be ·absent·.

Which I think implies that wildcards with namespace=##other do not
match unqualified elements (since their namespace name is absent).

If the description of {namespace constraint} summarises the intention,
the validation rule should be changed, so that it does not include
clause 2.3. If the validation rule defines the intention, then the
description of the {namespace constraint} should be changed, to remove
the ", or are not namespace qualified".

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/
Received on Wednesday, 2 January 2002 11:28:59 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 11 January 2011 00:14:26 GMT