Re: Inadvertently restricting mixed content

Thank you, Henry, for your input on this.

At 2005-02-05 11:40 +0000, Henry S. Thompson wrote:
>1) From the clause numbers you cite, I conclude you're looking at the
>original REC, not the second edition [1], which did clean up this
>aspect of things somewhat.  However, the changes _don't_ change that
>the 'mixed' on the <xs:complex...> of the _derived_ type determines
>the mixed of the result.

That was what I needed to know, that the derived type use of mixed= 
dictates the result use of mixed, regardless of the base use of mixed.

>2) Even were this not to be the case, you can't get what you want,
>because extending a content model _always_ results in a sequence of
>the old model and the new.  So if the old were e.g.
>
>    (a | b)*

But it's not because I'm dealing with mixed content.  I'm starting with only:

     ( #PCDATA )

by a complex type with mixed="true" and no elements, and I need

     ( #PCDATA | emph )*

by using emph* with mixed="true".

>and you extend it with (emph), you get
>
>    ((a | b)* , emph)
>
>which is not what you want anyway.

Right, but given that I'm only mixing new elements with PCDATA, I don't 
think that the extension restrictions are a problem when dealing with this 
particular situation.

>To achieve what your clients appear to want, you have to go around the
>houses in the following way:

I see where you are going with the redefined group, thanks:

>mixed.xsd:
>  <xs:group name="bits">
>...
>ext.xsd:
>  <xs:redefine schemaLocation="mixed.xsd">
>   <xs:group name="bits">
>    <xs:choice>
>...

Unfortunately, the base definition cannot be modified (it is the entryType 
in the OASIS Exchange XML Table Model) which is declared only as 
mixed="true" without any elements.  We need to treat the fragment as 
read-only.  Rather than involve the entire model and its distractions from 
the problem in this example I created the mini excerpt.

So, based on your (1) above, it looks like I'm still obliged to set 
mixed="true" in the derived declaration.  Which is fine ... the system is 
now working ... I just needed to tell the client this was the only way to 
deal with the situation since we are not in a position to change the base 
declaration.

Thanks again, Henry ... I always appreciate your assistance.

...................... 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 Saturday, 5 February 2005 18:10:39 UTC