Re: [xml] What's wrong with this schema?

[cazic gmx net]

Hi,

> Von: "Yong Chen (yongche)" <chen cisco com>
> Datum: Wed, 27 Jul 2005 11:38:05 -0700

> Hi,
>
> I'm having a problem loading this simple schema, the xmlSchemaParse()
> call fails:
>
> <?xml version="1.0" encoding="UTF-8"?>
>    <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema";
>               xmlns="http://myns";
>               targetNamespace="http://myns";
>               elementFormDefault="qualified"
>               attributeFormDefault="unqualified"
>               xml:lang="en">
>
>      <!--
>        Type for <data> element
>        -->
>      <xs:complexType name="dataInlineType">
>        <xs:complexContent>
>          <xs:extension base="xs:anyType"/>
>        </xs:complexContent>
>      </xs:complexType>
>
>    </xs:schema>
>
>
> The err is:
>
> ./x.xsd:12: element complexType: Schemas parser error : complex type
> 'dataInlineType': The content type must be the simple base type.
>
>
> Is that the "anyType" is not allowed here?

Your schema is OK.
This was a bug which had a bit of a rat-tail:
1. The "Derivation Valid (Extension)" (cos-ct-extends) constraint failed
  to recognize xs:anyType as a complex type
2. When this was fixed, clause 1.4.3 of the same constaint barked
  about the new type having no particle in the content type. In
  Libxml2 we didn't create the content type of xs:anyType, since it
  seemed not necessary and could be circumvented. So any _extended_
  type could not inherit any particle from xs:anyType.

Now it seems necessary to have a content type :-)

IMHO the pure fact that it is allowed to _extend_
xs:anyType - which I never thought about, since it doesn't do
anything - is a flaw in the spec. The only scenario where I can
imagine this can be used is to create an alias for the xs:anyType,
i.e. giving it an other name; but why would one do that?

Nevertheless, thanks for this report! Reports of such side cases are
highly appreciated! Keep them coming.
Interesting would be, if any added model group to the new defined type
would raise unique particle attribution (UPA) violations. Libxml2 does
not check for UPA yet - although most of the functions are there
already - so a comparison with other schema processors is recommended.

Fixed in CVS: xmlschemastypes.c (rev. 1.99), xmlschemas.c (rev. 1.161).
I added your test case to the regression tests.

Regards,

Kasimier