RE: [Bug report] XSV Restriction Error

Interesting revelation indeed.

I currently have a specification that should break if 1.1 is used.  

I have used any with "##any" + "strict" to allow for additional elements
within a type that can only be derived by restriction.  This is for two
reasons:

1. I want any additional content to be strictly validated, no matter the
namespace.  "lax" allows for opportunistic validation only, not strict
enough for me.

2. Existing elements may have type restrictions applied, while retaining the
same name, potentially in more than one step.

For example:

Top = (x : anyType, ##any)
Middle = (x : string, y : anyType)
Bottom = (x : string, y : string)

However, element y cannot be declared globally, as required by "strict"
because its type cannot then be restricted as shown.

How then do you suggest that I get around this little problem?  It seems
like my only option is to use processContents="lax" to get around the
problem.

For my own understanding, what benefit does this change provide?

Cheers,
Martin


-----Original Message-----
From: ht@inf.ed.ac.uk [mailto:ht@inf.ed.ac.uk] 
Sent: Tuesday, 19 April 2005 11:39 PM
To: Michael Kay
Cc: Thomson, Martin [WOLL:5500:EXCH]; xmlschema-dev@w3.org
Subject: Re: [Bug report] XSV Restriction Error


"Michael Kay" <mike@saxonica.com> writes:

> I haven't seen that extensional interpretation of ##any used before.

As I said, that's a bit of forward-looking to XML Schema 1.1 in XSV. . .

> What if there was a global declaration
>
> <xsd:element name="element" type="xsd:integer"/>
>
> Would it be the case that the restriction is invalid because none of 
> the possible elements that ##any might match has a type that's 
> compatible with xsd:token?

Yes, in 1.1 as currently envisaged.

> Or is there a rule somewhere that the restriction can only be a 
> reference to a globally-declared element?
>
> Saxon incidentally accepts the schema as supplied, although it also 
> uses an algorithm based on comparing the two FSA's to see if one 
> subsumes the other. However, it only checks the element name 
> ("element") against the set of namespaces permitted by the wildcard 
> ("##any"), it doesn't expand the wildcard into a finite set of 
> permitted element names.

That is correct per 1.0.

ht
-- 
 Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
                     Half-time member of W3C Team
    2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
            Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
                   URL: http://www.ltg.ed.ac.uk/~ht/
[mail really from me _always_ has this .sig -- mail without it is forged
spam]