George,

I was thinking of the concise option that you propose:

<xs:element name="impossible" final="#all" abstract="true"/>

I didn't choose it because it would have a peculiar problem of its own.

Let's consider XML data binding:

Let's say, we are using C# -- you would get something like:

    abstract sealed class Impossible
    {
    }

... which is rejected by the C# compiler for good reasons.

We are not just working around XSD issues but also language semantics
:-)

I guess what I am saying is that the revised XSD 1.0 should:

a) recommend that an implementation issues a warning for my definition.
b) ditto for your definition.
c) fix the actual problem with the interpretation of subtyping in
restriction.

Regards,
Ralf

http://www.cwi.nl/~ralf


> -----Original Message-----
> From: George Cristian Bina [mailto:george@o...]
> Sent: Monday, February 13, 2006 1:33 PM
> To: Ralf Lammel
> Cc: richard.liu@u...; mike@s...; xmlschema-dev@w...
> Subject: Re: E rcase-RecurseLax.1: Group's occurrence range,
> (1,unbounded), is not a valid restriction of base group's occurrence
> range, (1,1).
> 
> Hi Ralf,
> 
> That is an interesting approach! I would make the impossible element
> abstract instead of defining it to contain itself recursively:
> 
> <xs:element name="impossible" final="#all" abstract="true"/>
> 
> This has the advantage that the definition is shorter and the
impossible
> element should not be presented by content completion hints because it
> is abstract.
> 
> Now it is hard to say what part of the algorithm from the XML Schema
> specification rejects the empty sequence but anyway it is clear that
the
> content of the restricted type can be empty while the content of the
> base type cannot be empty which is clearly wrong.
> 
> Thanks for catching that,
> George


From Paul.Monday@S... Tue Feb 14 05:03:51 2006
Received: from wiggum.w3.org ([128.30.52.23])
	by fri