Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


RE: Inadvertently restricting mixed content

From: "Stan Kitsis" <skits@---------.--->
To: "G. Ken Holman" <gkholman@----------------.--->, <xmlschema-dev@--.--->
Date: 2/3/2005 5:37:00 AM
Hi Ken,

First, some clarification:

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).

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.

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.

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.

Stan

-----Original Message-----
From: xmlschema-dev-request@w... [mailto:xmlschema-dev-request@w...]
On Behalf Of G. Ken Holman
Sent: Thursday, February 03, 2005 11:46 AM
To: xmlschema-dev@w...
Subject: Inadvertently restricting mixed content


It appears that one cannot redefine a type and leave the mixed= nature
of 
the original type untouched, which would be important if it were not
known 
or, more important, arbitrary.

Looking at Part 1, Section 3.4.2, mixed= on <xsd:complexType> has a
default 
value of false.

Consider I might have a type with mixed content:

    <xsd:complexType name="abcType" mixed="true">
      <xsd:attribute ...>
      ...

Now, I redefine that type in an importing schema fragment:

    <xsd:redefine ...>
      <xsd:complexType name="abcType">
         <xsd:complexContent>
            <xsd:extension base="abcType">
               ...

The standard states there is an implicit mixed="false" because of the 
default value.  This turns off my mixed content, when all I wanted to do

was extend the existing type with some elements.

In this case I know I can just add mixed="true" in the redefinition to =

ensure the content is mixed ... but am I missing a way in which I can 
redefine a type while preserving its mixed= property?

My guess is no, because if I wanted to turn off the mixed content
property 
I would intuitively say mixed="false" ... but my intuition to leave it =

unchanged is to leave the attribute absent ... but when absent the
default 
value forces the redefinition to not be mixed.  So, it appears I have to

know a priori that a given type I'm redefining is mixed or not and the 
burden is on me to preserve it.

Have I read anything incorrectly in this regard?

Thanks for any guidance.

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

--
World-wide on-site corporate, govt. & user group XML/XSL training.
G. Ken Holman                 mailto:gkholman@C...
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




From skits@m... Fri Feb 04 22:18:17 2005
Received: from bart.w3.org ([128.30.52.40])
	by frink.w3.org with esmtp (Exim 4.34)
	id


transparent
Print
Mail
Like It
Disclaimer
.

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.

.
.

transparent

transparent