W3C home > Mailing lists > Public > xmlschema-dev@w3.org > June 2004

Re: Problem with types derived from mixed complex types

From: Tait E Larson <telarson@us.ibm.com>
Date: Wed, 16 Jun 2004 09:20:25 -0700
To: Achille Fokoue <achille@us.ibm.com>
Cc: ht@inf.ed.ac.uk (Henry S. Thompson), xmlschema-dev@w3.org
Message-ID: <OF44E8D78D.96B2F513-ON86256EB5.00557F99-88256EB5.00597E20@us.ibm.com>
From the error description [1] it seems that according to the original 
spec, complex types without child have empty content even if mixed="true" 
is specified.  In the revised spec, rule 2.1.4 at 3.4.2 XML Representation 
of Complex Type Definitions [2] it seems that 

<contentType name="foo" mixed="true"></contentType> 

is equivalent to 

<contentType name="foo" mixed="true">

I am not sure what significance this has except that the effective content 
is not empty and therefore 3.1.2 applies in this case instead of 3.1.1.

So, does <contentType name="foo" mixed="true"></contentType> have empty 
content?  I assume that this complex type actually has text for content.

I originally brought this issue up again [3] to see if Achille's example 
was correct.  It now seems that it is. However, I was originally given 
another example [4][5] which seems to accomplish the same thing and is 
also correct.  More explicitly, are the following complex type definitions 
"restr1" and "restr2" equivalent?

      <!-- the intend of  this type  is to simply remove all the children 
      <xs:complexType name='restr1' mixed='true'>
                  <xs:restriction base='base'>
                        <xs:attribute name='a1' />

  <xs:complexType name="restr2">
                  <xs:restriction base="base">
                              <restriction base="xs:string"/>
                        <xs:attribute name="a1" />

      <xs:complexType name='base' mixed='true'>
            <xs:choice minOccurs='0' maxOccurs='unbounded'>
                  <xs:element name='e1' type='xs:string'/>
            <xs:attribute name='a1'/>

If they are equivalent, why was an erratum needed to address this issue? 
Perhaps the issue was coincidentally solved by an erratum with a larger 

Thanks everyone for helping me get to the bottom of this.


[3] http://lists.w3.org/Archives/Public/xmlschema-dev/2004Jun/0013.html
[4] http://lists.w3.org/Archives/Public/xmlschema-dev/2004Jun/0014.html
[5] http://lists.w3.org/Archives/Public/xmlschema-dev/2004Jun/0015.html

Achille Fokoue/Watson/IBM
06/16/2004 06:30 AM

ht@inf.ed.ac.uk (Henry S. Thompson)
xmlschema-dev@w3.org, Tait E Larson/Burlingame/IBM@IBMUS
Re: Problem with types derived from mixed complex types


You are right. It is covered by erratum E1-5 [1].


[1] http://www.w3.org/2001/05/xmlschema-errata.html#E1-5
Achille Fokoue
Scalable XML Infrastructure
IBM T.J. Watson Research Center

To:     Achille Fokoue/Watson/IBM@IBMUS
cc:     xmlschema-dev@w3.org, Tait E Larson/Burlingame/IBM@IBMUS 
Subject:        Re: Problem with types derived from mixed complex types

Achille Fokoue <achille@us.ibm.com> writes:

> It seems that you have forgotten to add an erratum you mentioned in [1] 
> address the problem I reported in [2].
> Without this erratum, the following schema is considered invalid because 

> the spec simply ignores the "mixed" attribute of the 
> complex type restr:

I believe this _has_ been fixed, by E1-?? [1].  Or alternatively see
the mapping for {content type} in 3.4.2 XML Representation of Complex
Type Definitions [2].  Note in particular new clause 2.1.4 and changed
clauses and (the clause numbering is only correct in

If you think this doesn't cover the above case, please let me know


[1] http://www.w3.org/2001/05/xmlschema-errata.html#e1-??

 Henry S. Thompson, HCRC Language Technology Group, University of 
                     Half-time member of W3C Team
    2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
            Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
                   URL: http://www.ltg.ed.ac.uk/~ht/
[mail really from me _always_ has this .sig -- mail without it is forged 
Received on Wednesday, 16 June 2004 12:21:06 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:15:22 UTC