- From: Eliot Kimber <ekimber@innodata-isogen.com>
- Date: Fri, 09 Sep 2005 10:04:27 -0500
- 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. Hmmm. 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. Hmph. 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. Cheers, E. -- W. Eliot Kimber Professional Services Innodata Isogen 9390 Research Blvd, #410 Austin, TX 78759 (512) 372-8155 ekimber@innodata-isogen.com www.innodata-isogen.com
Received on Friday, 9 September 2005 15:02:08 UTC