Re: Permit (greedy) conflicting wildcards

Original Message From: "Bryan Rasmussen"

> >It says that under the current interpretation of XSD 1.1 the following
> >(slightly simplified from David's document) is illegal due to the
> >minOccurs="0" of middle name allowing the two adjacent wildcards to
> >conflict:
>
> >    <xs:sequence>
> >      <xs:element name="given" type="xs:string"/>
> >      <xs:any namespace="##any" processContents="lax"
> >              minOccurs="0" maxOccurs="unbounded"/>
> >      <xs:element name="middle" type="xs:string" minOccurs="0"/>
> >      <xs:any namespace="##any" processContents="lax"
> >              minOccurs="0" maxOccurs="unbounded"/>
> >      <xs:element name="family" type="xs:string"/>
> >    </xs:sequence>
>
>
> Well I would have thought that it should also be illegal because I 
> wouldn't
> know if any element name (other than given) is one of the unbounded any? 
> Hmm,
> i seem to remember somewhere a discussion as to whether or not an element 
> in
> a structure that was a known should cause the any from stopping, which I
> guess this would be a case of, but I can't remember the outcome. At any 
> rate
> I think it's problematic.

The current rules in XSD 1.1 says that if an element and a wildcard 
conflict, then the element wins.

> >    <xs:sequence>
> >      <xs:any namespace="##any" processContents="lax"
> >              minOccurs="0" maxOccurs="unbounded"/>
> >      <xs:any namespace="##any" processContents="lax"
> >              minOccurs="0" maxOccurs="unbounded"/>
> >      <xs:any namespace="##any" processContents="lax"
> >              minOccurs="0" maxOccurs="unbounded"/>
> >    </xs:sequence>
>
> >they should be allowed to do it and it wouldn't be an error.
>
> I suppose this should also be allowed but not only do I doubt its 
> usefulness
> I doubt its implementation would be uniformly achieved.

This is similar to a regular expression of the form:

    /(\w*)(\w*)(\w*)/

This is quite legal (although not necessarily sensible!).  Also, if you had 
an input string like:

    abcdefghijkl

It's quite deterministic about the outcome, it's uniformly implemented and 
there is no ambiguity.

The XSD case should be the same.

BTW, the former case is analogous to a regular expression of the form 
(representing each element as a single letter):

    /^(G)([^GMF]*)(M?)([^GMF]*)(F)$/

Again, this is completely deterministic, has no ambiguity and is uniformly 
implemented.

Thanks for your comments,

Pete.

P.S. Quick Perl script for those that want to play:

#!/usr/bin/perl

testit('GMF');
testit('GajhvMjhbkjF');
testit('GkjhgkjMF');
testit('GMkjhgkjF');
testit('GF');
testit('GljkjhgkjhF');

testit('jkhghGMF');
testit('GMFjhgkj');
testit('MF');
testit('ajhvMjhbkjF');
testit('GkjhgkjM');
testit('kjhgkjF');
testit('GM');
testit('GljkjhgkjhM');

sub testit()
{
    if( $_[0] =~ /^(G)([^GMF]*)(M?)([^GMF]*)(F)$/ ) {
        print "In: $_[0]\n1: $1\n2: $2\n3: $3\n4: $4\n5: $5\n\n";
    }
    else {
        print "In $_[0]\nNo Match\n\n";
    }
}

--
=============================================
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/
=============================================

Received on Monday, 19 March 2007 10:08:43 UTC