- From: Ralf Lammel <Ralf.Lammel@microsoft.com>
- Date: Mon, 13 Feb 2006 14:37:39 -0800
- To: "George Cristian Bina" <george@oxygenxml.com>
- Cc: <richard.liu@ubs.com>, <mike@saxonica.com>, <xmlschema-dev@w3.org>
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@oxygenxml.com] > Sent: Monday, February 13, 2006 1:33 PM > To: Ralf Lammel > Cc: richard.liu@ubs.com; mike@saxonica.com; xmlschema-dev@w3.org > 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
Received on Monday, 13 February 2006 22:38:06 UTC