At 11:09 PM 7/13/2004 +0100, Michael Kay wrote:

>FWIW, Saxon 8.0 also accepts this schema as valid.

Thanks, I just downloaded Saxon to add to my test suite.

>When you get into boundary cases, taking a majority vote of what products do
>is not very good evidence of what the spec says (or intended to say).

Very true, but I'm just trying to come up with a set of schemas that most 
processors are happy with, and what error messages to ignore when 
"conforming" processors disagree.

>  But
>the spec seems to go out of its way to say that maxOccurs="0" is legal
>almost everywhere, so I can't quite see why the issue is in doubt.

Just the usual problems trying to convince a programmer that there may 
bug  may  be in _their_ code and not someone else's.  In this case the 
person is asserting that restricting anyType is different than restricting 
other types and anyType can't be restricted to maxOccurs="0".  Before I 
start quoting bits of the spec to someone who knows it much better than I 
ever will I want to make sure that I (look like I) know what I'm talking 
about and that my argument (below) is sound.

Cheers,
Keith


> > -----Original Message-----
> > From: xmlschema-dev-request@w...
> > [mailto:xmlschema-dev-request@w...] On Behalf Of Keith Suderman
> > Sent: 13 July 2004 22:23
> > To: xmlschema-dev@w...
> > Subject: [xmlschema-dev] <none>
> >
> > Hello,
> >
> > I asked a similar question earlier, but I would like
> > clarification since I
> > didn't make it clear earlier that I wanted to restrict xs:anyType.
> >
> > Is the following schema valid?
> >
> > <?xml version="1.0" encoding="UTF-8"?>
> > <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > elementFormDefault="qualified" attributeFormDefault="unqualified">
> >          <xs:element name="root" type="empty"/>
> >
> >          <xs:complexType name="empty">
> >                  <xs:complexContent>
> >                          <xs:restriction base="xs:anyType">
> >                                  <xs:sequence>
> >                                          <xs:any minOccurs="0"
> > maxOccurs="0" processContents="lax"/>
> >                                  </xs:sequence>
> >                          </xs:restriction>
> >                  </xs:complexContent>
> >          </xs:complexType>
> > </xs:schema>
> >
> >
> > XSV 2.5, XMLSpy">XMLSpy, and Xerces-J 2.6.2 all accept this schema
> > as valid, but
> > Xerces-C 2.5 reports an error claiming that maxOccurs=0 is
> > illegal.  When
> > this was pointed out on the xerces-c list the folks there seemed
> > unconvinced and replied:
> >
> >  >'the derivation by restriction has some constraints, for
> > some reference,
> >  >please see the following table:
> >  >http://www.w3.org/TR/xmlschema-0/#restrictsTable and
> >
> > >http://www.w3.org/TR/xmlschema-1/#section-Built-in-Complex-Ty
> > pe-Definition
> >  >You'll see that anyType has { minOccurs, maxOccurs } as {
> > 1, 1 } which
> >  >can't be restricted.'
> >
> > As I understand it, the restrictsTable referred to above
> > (which has been
> > amended in an errata [1]) only "shows several examples" of
> > how element
> > definitions may be restricted, it's not an exhaustive list of what is
> > allowed.  Also, case 5.3 of [2] says "the particle of the
> > complex type
> > definition itself must be a .valid restriction. of the
> > particle of the
> > {content type} of the {base type definition}".  In the built
> > in complex
> > type definition [3] the {particle} of the {content type} is a
> > sequence with
> > {minOccurs, maxOccurs} = {0, unbounded}, which can be
> > restricted to {0, 0}.
> > However, I'm unlikely to convince anyone on the Xerces-C list
> > that the
> > above schema is correct (or that everyone else is wrong)
> > without some sort
> > of confirmation from this list.
> >
> > Finally, is
> >
> >          <xs:complexType name="empty"/>
> >
> > equivalent (in the sense that <root/> is the only valid
> > document) to the
> > definition above?
> >
> > Thanks in advance,
> > Keith
> >
> > References
> >
> > [1] http://www.w3.org/2001/05/xmlschema-errata.html#e0-20
> > [2] http://www.w3.org/TR/xmlschema-1/#derivation-ok-restriction
> > [3]
> > http://www.w3.org/TR/xmlschema-1/#section-Built-in-Complex-Typ
> > e-Definition
> >
> >
> > --------------------------------------------------
> > Keith Suderman
> > Technical Specialist
> > American National Corpus
> > suderman@c...
> > http://americannationalcorpus.org
> >
> >

--------------------------------------------------
Keith Suderman
Technical Specialist
American National Corpus
suderman@c...
http://americannationalcorpus.org

From rschloss@u...  Sun Jul 18 08:52:38 2004
Return-Path: <rschloss@u...>
X-Original-To: xmlschema-dev@l...
Delivered-To: xmlschema-dev@l...