W3C home > Mailing lists > Public > xmlschema-dev@w3.org > September 2005

Re: Must You Specify mixed="true" on extended types?

From: Eliot Kimber <ekimber@innodata-isogen.com>
Date: Fri, 09 Sep 2005 10:04:27 -0500
Message-ID: <4321A47B.2000501@innodata-isogen.com>
To: "'xml-schema-dev'" <xmlschema-dev@w3.org>

George Cristian Bina wrote:

> I think that Xerces is right here.
> The extended type has an empty effective content which means that its content type property is the same as the one of the base type, see the rules for computing the content type for complex types with complex content:
> http://www.w3.org/TR/xmlschema-1/#Complex_Type_Definition_details
> ***
> 3.2 If the <extension> alternative is chosen, then  the appropriate case among the following:
> 3.2.1 If the ·effective content· is empty, then the {content type} of the type definition ·resolved· to by the ·actual value· of the base [attribute]

I see what George is getting at and I think I agree with his analysis: 
IF the extending content model is empty (adds no new elements to the 
base) THEN the local value of the mixed= attribute is ignored. If it is 
not empty then it is not ignored and, if unspecified, the default value 
of "false" is used.

Michael Kay wrote:
>>But I wanted to make sure, because I would have expected the 
>>value for 
>>"mixed" to be inherited from the base type for extensions, 
>>regardless of 
>>what the nominal default value of the "mixed=" attribute is.
> I don't think there's anything in the spec that causes the default to be
> inherited from the base type. It has to be specified explicitly and it has
> to be consistent. That's the XML schema style - like listing all the child
> elements again when you define a type by restriction.

So Mike is also correct: mixed is not inherited if left unspecified: I 
think the spec is clear in that there is an explicit default value of 
"false". Therefore my initial naive expectation is unsupported by the spec.

This feels like Simon Says behavior in that 99% of the time the author 
of the extended type will want the value for mixed= to be the same as 
the base and why force the author to restate it?

However, in thinking about it I can see that there is the case where an 
extension author who wants the extension to have a different mixed value 
from the base should always get a failure when they don't match. In 
particular, in the case where the base specifies mixed="true" and the 
extension leaves mixed= unspecified, knowing that the default value of 
"fixed" is what is desired, the extension author may be (unpleasantly) 
surprised if he leaves mixed= unspecified and subsequently discovers 
that his extended type allows PCDDATA content. This is a failure on the 
extension author's part but it is a failure that should be reported clearly.


I don't think this is the more common case but I can't also suggest that 
the convenience of the many should come at the cost of silent failures 
to impose the author's intent.


So in my case, even though I think George is correct and that in my 
specific case no error should be reported per the words of the spec, 
maybe it should be since the case when the error is not reported and 
when it is quite subtle.

That is, if I ever come back and add an element to my previously-empty 
extended type, I will definitely get a failure and I will be confused by 
it since I didn't get it before. Without a close reading of the spec I 
will have a hard time coming to understand why it suddently started failing.

Thus better in this case to *always* fail, imposing a simple rule: 
"mixed= values must always match." Just because. Trust me. I'm the Dad. 
Don't ask so many questions. You'll undestand when you're older.


W. Eliot Kimber
Professional Services
Innodata Isogen
9390 Research Blvd, #410
Austin, TX 78759
(512) 372-8155

Received on Friday, 9 September 2005 15:02:08 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:56:08 UTC