Re: Permit (greedy) conflicting wildcards

Pete Cordell wrote:

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

I think I understood that, but I'm not convinced it's what I want when 
writing schemas.  Let's say you're writing an extensible schema for the 
HTML table element.  HTML 4 says it can have (in DTD syntax): 

        CAPTION?, (COL*|COLGROUP*), THEAD?, TFOOT?, TBODY+

Let's say I want to add one of these new wildcards:

        CAPTION?, (COL*|COLGROUP*), THEAD?, TFOOT?, TBODY+, NewWC*

By your rule, that would disallow:

        <TABLE>
                <CAPTION>...</CAPTION>
                <TBODY>...</TBODY>
                <CAPTION>...</CAPTION>
        </TABLE>

but would allow:

        <TABLE>
                <CAPTION>...</CAPTION>
                <TBODY>...</TBODY>
                <!-- Do you really want the following to match the WC? -->
                <HTML>...</HTML>
        </TABLE>

The point of the Not In Schema Wildcard is that you know about things like 
HTML, and if you wanted them, you would have mentioned them explicitly. 
The wildcard is presumably for extensions you've never heard of.  I do 
understand your proposal, I think, but I'm not convinced it gives us what 
we want.

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








"Pete Cordell" <petexmldev@tech-know-ware.com>
04/04/2007 06:04 AM
 
        To:     <noah_mendelsohn@us.ibm.com>
        cc:     <xmlschema-dev@w3.org>
        Subject:        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 Monday, 9 April 2007 21:25:30 UTC