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 Saturday, 24 March 2007 21:14:03 UTC