RE: Semantics of elementFormDefault / Form

Thanks, Priscilla.  This is very helpful.

--Judy

-----Original Message-----
From: Priscilla Walmsley [mailto:pwalmsley@vitria.com]
Sent: Wednesday, January 02, 2002 2:46 PM
To: Slein, Judith A; Jeni Tennison; xmlschema-dev@w3.org
Cc: Priscilla Walmsley; Kurian, Binil; Sembower, Neil R; Graham Mann
Subject: RE: Semantics of elementFormDefault / Form


Hi Judy,

As far as a definitive answer about ##other, it definitely does not
allow elements in no namespace.  The working group is currently writing
up an erratum description to correct the contradiction in the
specification.

As for you new example, I don't see an ambiguity because as Jeni said,
the JDFChildElements_ are qualified with the other namespace, and
ResourceLinkPool is unqualified.  

However, if the form of the ResourceLinkPool element _were_ qualified,
it would be ambiguous because it would conform to the ##other wildcard.
The wildcard, like the element declarations, takes on the namespace of
the schema document in which it is declared.  So, in your case, ##other
means "any element that is in a namespace other than
"http://www.CIP4.org/JDFSchema_1".  Since all the elements in the type
are optional, if the processor encountered an em:ResourceLinkPool
element it would not know if it matched the wildcard or the element
declaration.

Hope that helps,
Priscilla
------------------------------------------------------------------
Priscilla Walmsley                          priscilla@walmsley.com
Vitria Technology                            http://www.vitria.com
Author, Definitive XML Schema                  (Prentice Hall PTR)
------------------------------------------------------------------

> -----Original Message-----
> From: xmlschema-dev-request@w3.org
> [mailto:xmlschema-dev-request@w3.org]On Behalf Of Slein, Judith A
> Sent: Wednesday, January 02, 2002 11:29 AM
> To: 'Jeni Tennison'; xmlschema-dev@w3.org
> Cc: Priscilla Walmsley; Slein, Judith A; Kurian, Binil; Sembower, Neil
> R; 'Graham Mann'
> Subject: RE: Semantics of elementFormDefault / Form
> 
> 
> 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/Emai
> lDistMsgLayer"
> 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 14:54:02 UTC