[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

RE: [xsl] Bug in Schema for XSLT 2.0?

---

---

The right place for this comment is public-qt-comments@xxxxxx

However, I believe the schema is correct (we certainly put a lot of effort
into getting this part correct, which is known to be tricky.)

The schema specification allows a complex type with simple content to be
derived by restriction from a complex type with mixed content. If you look
in Schema Part 1 section 3.4.2, at the section titled "Complex Type
Definition with simple content Schema Component", under "content type", we
read that the content type is:

2 If the type definition 7resolved7 to by the 7actual value7 of the base
[attribute] is a complex type definition whose own {content type} is mixed
and a particle which is 7emptiable7, as defined in Particle Emptiable
('3.9.6) and the <restriction> alternative is chosen, then starting from the
simple type definition corresponding to the <simpleType> among the
[children] of <restriction> (which must be present) a simple type definition
which restricts that simple type definition with a set of facet components
corresponding to the appropriate element information items among the
<restriction>'s [children] (i.e. those which specify facets, if any), as
defined in Simple Type Restriction (Facets) ('3.14.6);

Don't blame me for that sentence!

So, firstly this is saying that you can derive a complex type with simple
content by restriction from a complex type with mixed content, provided that
the complex type with mixed content is emptiable (which means that no child
elements are required). Then it is saying that if you do that, the
xs:restriction element must have a child xs:simpleType element to describe
the type of the simple content. It then allows that simple type definition
to contain restricting facets - but we want to allow any string inside
<xsl:text>, so we haven't included any such facets: which is explicitly
permitted by the phrase "if any".

All these conditions are satisfied by the definition that you quoted.

If you don't believe this is valid, you need to tell us which rule in the
schema spec you think it violates.

Reputable schema processors such as Xerces, XSV, and Saxon all accept this
schema.

Michael Kay


> -----Original Message-----
> From: Peter Gerstbach [mailto:peter@xxxxxxxxxxxx]
> Sent: 15 February 2005 10:55
> To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
> Subject: [xsl] Bug in Schema for XSLT 2.0?
>
> Hello,
>
> I think I found a bug in the non-normative Schema for XSLT 2.0 at
> http://www.w3.org/2005/02/schema-for-xslt20.xsd
>
> This snippet is from there:
>
> <xs:complexType name="text-element-base-type">
>   <xs:simpleContent>
>     <xs:restriction base="xsl:versioned-element-type">
>       <xs:simpleType>
>         <xs:restriction base="xs:string"/>
>       </xs:simpleType>
>       <xs:anyAttribute namespace="##other" processContents="lax"/>
>     </xs:restriction>
>   </xs:simpleContent>
> </xs:complexType>
>
> It is a complexType with a simpleContent, but the specified
> "versioned-element-type" does not have simple content.
> But changing the second line (<xs:simpleContent>) to
> complexContent does not
> resolve the problem, because as I know, you cannot have a
> simpleType definition
> inside a restriction. Am I right?
> For me it is also not really clear, what this simpleType
> inside the restriction
> should mean.
>
> regards,
> Peter

---