Element + complextype name in xml schema

[Nicolas Mailhot]

Hi,

I've been sent an xsd that uses the following construct :

<xsi:element name="foo">
<xsi:complexTyp e name="foo">

Is this something allowed ? I couldn't find anything that said it's
wrong, but at the same time I have an xml parser that chokes on it and
none of the public xsd examples I've ever seen used it. I'd like to
know if I should file a bug on the parser or if I can tell the people
that send me the schema their definition does not fly.

I've little experience on xml schemas so far though it looks like I'm
up for an accelerated course.

Regards,

--
Nicolas Mailhot

[Martin Honnen]

Nicolas Mailhot wrote:

I've been sent an xsd that uses the following construct :

<xsi:element name="foo">
<xsi:complexTyp e name="foo">

Is this something allowed ? I couldn't find anything that said it's
wrong, but at the same time I have an xml parser that chokes on it and
none of the public xsd examples I've ever seen used it. I'd like to
know if I should file a bug on the parser or if I can tell the people
that send me the schema their definition does not fly.

I think it is allowed to have types and elements with the same name as
different scopes are used for type names and for element names.
I am however not sure it makes sense to have a name attribute on that
anonymous type nested inside the element declaration, usually if you
want to name a type you use
<xsd:complexTyp e name="foo">
...
</xsd:complexType >

<xsd:element name="foo" type="foo" />
--

Martin Honnen
http://JavaScript.FAQTs.com/

[Nicolas Mailhot]

On Fri, 08 Apr 2005 17:36:33 +0200, Martin Honnen wrote:

I am however not sure it makes sense to have a name attribute on that
anonymous type nested inside the element declaration,

Sure, if it made sense it'd be used more often. But before I complain
about it I'd like to be dead-sure it's not allowed - if it were my own xsd
this would be different.

I _so_ wish there was an w3c validator service for xsds. The specs
themselves are sometimes not readable by mere mortals, and who's to say
one third-party tool is more right than another ?

Regards

--
Nicolas Mailhot

[Martin Honnen]

Nicolas Mailhot wrote:

But before I complain
about it I'd like to be dead-sure it's not allowed - if it were my own xsd
this would be different.

I have had a look through
http://www.w3.org/TR/xmlschema-1/#Co...pe_Definitions
and can't find anything in there suggesting that the name attribute on
xs:complexType is only allowed in certain cases or disallowed in other
cases.

However both Xerces Java as well as MSXML complain about that case and
indeed the schema for schemas says for topLevelComplex Type

<xs:complexTy pe name="topLevelC omplexType">
<xs:complexCont ent>
<xs:restricti on base="xs:comple xType">
<xs:sequence>
<xs:element ref="xs:annotat ion" minOccurs="0"/>
<xs:group ref="xs:complex TypeModel"/>
</xs:sequence>
<xs:attribute name="name" type="xs:NCName " use="required"/>
<xs:anyAttribut e namespace="##ot her" processContents ="lax"/>
</xs:restriction>
</xs:complexConte nt>

so there the name attribute is required while for localComplexTyp e

<xs:complexTy pe name="localComp lexType">
<xs:complexCont ent>
<xs:restricti on base="xs:comple xType">
<xs:sequence>
<xs:element ref="xs:annotat ion" minOccurs="0"/>
<xs:group ref="xs:complex TypeModel"/>
</xs:sequence>
<xs:attribute name="name" use="prohibited "/>
<xs:attribute name="abstract" use="prohibited "/>
<xs:attribute name="final" use="prohibited "/>
<xs:attribute name="block" use="prohibited "/>
<xs:anyAttribut e namespace="##ot her" processContents ="lax"/>
</xs:restriction>
</xs:complexConte nt>
</xs:complexType>

the name attribute is prohibited.

So you should complain if someone sends you a schema with
<xs:element name="element-name">
<xs:complexTy pe name="type-name">
as the name attribute on the local complex type is prohibited thus the
schema is not valid.

--

Martin Honnen
http://JavaScript.FAQTs.com/

[Nicolas Mailhot]

Hi all,

For those who wonder I posted the same question on the w3c schema list
and everyone agreed this construct was forbidden by the spec (look up
the thread in archives for all the normative quotations)

So my problem is solved.

Thanks to everyone involved here

--
Nicolas Mailhot