RE: Inadvertently restricting mixed content

Ken,

Sorry if I was unclear.  Yes, you are correct.  You have to specify the
mixed attribute for the derived type if you want it to have mixed
content.

Stan

-----Original Message-----
From: xmlschema-dev-request@w3.org [mailto:xmlschema-dev-request@w3.org]
On Behalf Of G. Ken Holman
Sent: Thursday, February 03, 2005 3:49 PM
To: xmlschema-dev@w3.org
Subject: RE: Inadvertently restricting mixed content


Thank you Dan and Stan for the responses.

At 2005-02-03 13:37 -0800, Stan Kitsis wrote:
>When you derive a new type by extension, you add new content after the
>existing content of the base class and you cannot change the existing
>content.  Therefore, it is impossible to change the value of mixed
>attribute when deriving new types by extension (so you can't go from
>mixed to non-mixed or vice versa when deriving by extension).

That makes sense in prose, but it doesn't mesh with what I read in the 
spec, detailed below.

>When you derive a new type by restriction, you create a content model
>which is a subset of the base type.  Therefore, you cannot create a
>mixed type when deriving by restriction from non-mixed type.

Fine, but I'm doing extension.  I'm trying to add optional elements to 
mixed content.

>The only possible case is when deriving by restriction from a mixed
base
>type.  The value of mixed attribute is not passed to the derived type.
>So you have to specify it if you want the new type to be mixed.

Yes, I see in the spec that the value of the mixed attribute is not
passed 
to the derived type, noted below.

>With this in mind, your question becomes "Should I know what the base
>type is when deriving from it by restriction?"  And I think the answer
>is a definite yes.  Since your derived type should be a valid subset of
>the base type, you have to know what the base type is.

Again, that makes sense, but it isn't the situation in which I find
myself 
because I'm trying to do extension, not restriction:

V:\samp>type mixedre1.wxs
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">

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

<xsd:complexType name="fooType" mixed="true"/>

</xsd:schema>

V:\samp>type mixedre2.wxs
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<xsd:redefine schemaLocation="mixedre1.wxs">
   <xsd:complexType name="fooType">
     <xsd:complexContent>
       <xsd:extension base="fooType">
         <xsd:sequence>
           <xsd:element name="emph" minOccurs="0">
             <xsd:complexType mixed="true"/>
           </xsd:element>
         </xsd:sequence>
       </xsd:extension>
     </xsd:complexContent>
   </xsd:complexType>
</xsd:redefine>

<xsd:element name="fooEmph" type="fooType"/>

</xsd:schema>

V:\samp>type mixedre3.xml
<fooEmph>Hello <emph>great</emph> world.</fooEmph>
V:\samp>

So, in the above <fooEmph>, the intuition would be to allow emphasis 
elements in mixed content, and that is consistent with when you say it
is 
"impossible to change the value of mixed attribute when deriving new
types 
by extension", but walking through the spec in detail doesn't come to
that 
conclusion.  To get my instance to validate, I am obliged to add 
mixed="true" in the redefinition of the type.  The base type's value for

mixed is not being used.

In 3.4.2, the section "Complex Type Definition with complex content"
applies.

I'm looking at the {content type} property.

Case 2 applies because I'm doing extension.

Case 2.1 does not apply because the content is not empty.

Case 2.2 does not apply because the base definition is not empty.

Case 2.3 applies, and it points to case 1.2.1.  This is the restriction 
business that you say above "The only possible case is when deriving by 
restriction from a mixed base type.  The value of mixed attribute is not

passed to the derived type.", but it explicitly comes into play now when

I'm trying to do extension.

Case 1.2.1.1 does not apply because the mixed attribute is not present
on 
<complexContent>.

Case 1.2.1.2 does not apply because the mixed attribute is not present
on 
<complexType>

Case 1.2.1.3 applies, and it forces the content to be elementOnly.

Therefore, there is no reference to the mixed attribute of the base type

when doing extension in the redefinition.

Therefore, I'm obliged to specify mixed="true" in the redefinition in
order 
to make it mixed (1.2.1.1 or 1.2.1.2) when doing extension.

Therefore, when doing extension, as you say for restriction, "you have
to 
specify it if you want the new type to be mixed."

I am witnessing this behaviour during validation, and I'm trying to
justify 
to someone who is making your claim, Stan, that extension shouldn't
change 
the mixed property, that I have to change their redefinition by adding
the 
mixed="true".  So I'm trying to quote chapter and verse to prove that I
do, 
indeed, even in extension, have to specify the mixed nature in the 
redefinition.

Have I read the spec incorrectly?  It looks to me like the spec is 
unambiguous in this regard.  I'm trying to find out where (or if) I'm 
wrong.  My customer is challenging my claim that I'm obliged to add this

attribute in the redefinition.

Thanks again for your comments, Stan.

................... Ken

--
World-wide on-site corporate, govt. & user group XML/XSL training.
G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/x/
Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
Male Breast Cancer Awareness  http://www.CraneSoftwrights.com/x/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal

Received on Friday, 4 February 2005 22:18:17 UTC