Re: Permit (greedy) conflicting wildcards

Possibly I confused everyone with this example!

I think what I want can be more simply stated as, an element information 
item in an instance can not be validated by a wild card if the information 
item's name matches that of an element declaration that corresponds to a 
potential sibling of the information item in an XML instance.

HTH,

Pete.
--
=============================================
Pete Cordell
Tech-Know-Ware Ltd
for XML to C++ data binding visit
http://www.tech-know-ware.com/lmx/
http://www.codalogic.com/lmx/
=============================================

----- Original Message ----- 
From: "Pete Cordell" <petexmldev@tech-know-ware.com>
To: <noah_mendelsohn@us.ibm.com>
Cc: <xmlschema-dev@w3.org>
Sent: Saturday, March 24, 2007 10:13 PM
Subject: Re: Permit (greedy) conflicting wildcards


>
> Hi Noah,
>
> I think it's simpler than that.  If I have an element declaration of 
> (which hopefully includes most of the relationships a particle might 
> have):
>
>    <xs:element name="example" type="exampletype"/>
>
>    <xs:complexType name="exampleType">
>        <xs:complexContent>
>            <xs:extension base="exampleBase">
>                <xs:sequence>
>                    <xs:element ref="other:e1"/>
>                    <xs:element name="e2" type="xs:int"/>
>                    <xs:any notQName="##localElements"
>                                minOccurs="0" maxOccurs="unbounded"/>
>                    <xs:group ref="aGroup"/>
>                    <xs:sequence maxOccurs="10">
>                        <xs:element ref="other:e3"/>
>                        <xs:any notQName="##localElements"
>                                minOccurs="0" maxOccurs="unbounded"/>
>                        <xs:choice>
>                            <xs:element name="es1" type="xs:int"/>
>                            <xs:element name="es2" type="xs:int"/>
>                        </xs:choice>
>                    <xs:element name="e4">
>                        <xs:complexType>
>                            <xs:sequence>
>                                <xs:element name="ec1" type="xs:int"/>
>                            </xs:sequence>
>                        </xs:complexType>
>                    </xs:element>
>                    </xs:sequence>
>                </xs:sequence>
>            </xs:extension>
>        </xs:complexContent>
>    </xs:complexType>
>
>
>    <xs:complexType name="exampleBase">
>        <xs:sequence>
>            <xs:element name="eb1" type="xs:int"/>
>            <xs:any notQName="##localElements"
>                    minOccurs="0" maxOccurs="unbounded"/>
>        </xs:sequence>
>    </xs:complexType>
>
>    <xs:group name="aGroup">
>        <xs:sequence>
>            <xs:element name="eg1" type="xs:int"/>
>            <xs:any notQName="##localElements"
>                                minOccurs="0" maxOccurs="unbounded"/>
>        </xs:sequence>
>    </xs:group>
>
> (I've called the wildcard ##localElements so that it is different to 
> ##defined, which I believe already has a defined meaning.)
>
> So in the set of valid instances, any element name in the type mentioned 
> above that could have the parent <element> (or what ever element 
> exampleType was used to define) should be referred to in the notQName 
> definition.
>
> Therefore, in the context of decoding an instance of <element>, then ALL 
> of the wildcards would effectively be:
>
>            <xs:any notQName="eb1 other:e1 e2 other:e3 e4 es1 es2 eg1"
>                                minOccurs="0" maxOccurs="unbounded"/>
>
> Note that ec1 is not included in the set (because it is the child of 
> another element), and there's no reference to any potential parent of 
> <element>.  In fact, a wildcard matching <element> would be valid.
>
> However, when aGroup is used in a different complexType, or exampleBase is 
> used with a different derived class, the resulting exclusions would be 
> different in those cases (as they would be with the currently proposed XSD 
> 1.1 UPA conflict rules).
>
> I hope that makes it clearer.
>
> Thanks,
>
> Pete.
> --
> =============================================
> Pete Cordell
> Tech-Know-Ware Ltd
> for XML to C++ data binding visit
> http://www.tech-know-ware.com/lmx/
> http://www.codalogic.com/lmx/
> =============================================
>
> ----- Original Message ----- 
> From: <noah_mendelsohn@us.ibm.com>
> To: "Pete Cordell" <petexmldev@tech-know-ware.com>
> Cc: <xmlschema-dev@w3.org>
> Sent: Saturday, March 24, 2007 4:34 PM
> Subject: Re: Permit (greedy) conflicting wildcards
>
>
>> Pete Cordell writes:
>>
>>> If not the default, then what I'm looking for is something like:
>>>
>>>     notQName="##localElements"
>>>
>>> which does not conflict with any of the elements that have already been
>>> defined in the particle (and non-elemental child particles, and parents
>> of
>>> non-elemental particles etc. etc.)
>>
>> Let me get this straight.  You have a schema that validates instances
>> like:
>>
>> <root>
>>   <l1a/>
>>   <l1b/>
>>   <l1c>
>>     <l2a>
>>     </l2a>
>>     <l2b>
>>        <l3a/>
>>        <l3b/>
>>     </l2b>
>>     <l2c>
>>     </l2c>
>>   </l1c>
>>   <l1d/>
>>   </root
>>
>> In case it's not clear, <lxy> decodes as nesting level=x.    Presume 
>> these
>> are defined with the obvious sequences and global element decls in the
>> schema.  Let's assume that type CT12b is the complex type of the element
>> named "l1c".  If I use a wildcard in that type:
>>
>>        <complexType name="ctlic">
>>                <sequence>
>>               <element ref="l12a"/>
>>               <element ref="l12b"/>
>>               <element ref="l12c"/>
>>                   <any notQname="##defined"/>
>>                </sequence>
>>        </complesType>
>>
>> You want that wildcard to disallow <root> <l12a> <li12b> <l12c> and maybe
>> <l13a> and <l13b> (not sure if you meant descendents or children), but 
>> you
>> would not disallow <l1a> or <l1b> which are siblings?
>>
>> Let's take an example from the schema language itself.  If we used an NIS
>> wildcard in the declaration of the <xsd:sequence> element, for example, 
>> it
>> would not match <xsd:element>, because that's already directly referenced
>> as a legal child of <xsd:sequence>.  It would, however, allow
>> <xsd:import>, since that is neither a legal ancestor or declared
>> descendent.  So, it would validate:
>>
>>                <xsd:sequence>
>>               <xsd:element ref="x"/>
>>               <xsd:import namespace="n"/>
>>                </xsd:sequence>
>>
>> Interestingly, I do not think it would validate
>>
>>                <xsd:sequence>
>>               <xsd:element ref="x"/>
>>               <xsd:redefine ... />
>>                </xsd:sequence>
>>
>> because I believe that <xsd:sequence> is a legal descendent of
>> <xsd:redefine>.     Is that really what you want?  Could you please
>> clarify what you think is desirable?  Thank you.
>>
>> Noah
>>
>> --------------------------------------
>> Noah Mendelsohn
>> IBM Corporation
>> One Rogers Street
>> Cambridge, MA 02142
>> 1-617-693-4036
>> --------------------------------------
>>
>>
>>
>>
>
>
>
>

Received on Wednesday, 4 April 2007 10:05:01 UTC