You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-users@xerces.apache.org by Michael Glavassevich <mr...@ca.ibm.com> on 2010/10/10 23:20:32 UTC

Fw: Re: Representation of complex types derived by extension


(Forwarding a message from Jeff Greif to the list that got lost in the
moderation queue.)

----- Message from Jeff Greif <jg...@alumni.princeton.edu> on Tue, 28 Sep
2010 10:13:16 -0700 -----

> Thanks very much, Michael.
>
> Related questions:
>
> If there is
>
> <extension base="X">
>     <all>...</all>
> </extension>
>
> I would expect that either X has no element content or a content model
> of <all>, with some compatibility constraint between the <all>
> particles of base and extension.  Since <sequence> must not have an
> <all> child, presumably the {content type} must be modeled as a pair
> containing a particle with {all} term.
>
> 1.  must X have empty element content or is something else possible?
>
> 2.  is the element-content part of {content type} represented as a
> particle with a single {all} term?
>
> Jeff
>
> On Sat, Sep 18, 2010 at 2:19 PM, Michael Glavassevich
> <mr...@ca.ibm.com> wrote:
> > Hi Jeff,
> >
> > What you are getting from the XSModel is consistent with the definition
of
> > the {content type} in the XML Schema 1.0 spec. For an extension it's a
> > sequence of two particles; a particle for the base content followed by
a
> > particle containing the effective content [1] from the extension. Below
the
> > anchor [1] you'll see the formal definition in 3.2.3.
> >
> > Thanks.
> >
> > [1] http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/#key-exg
> >
> > Michael Glavassevich
> > XML Parser Development
> > IBM Toronto Lab
> > E-mail: mrglavas@ca.ibm.com
> > E-mail: mrglavas@apache.org
> >
> > Jeff Greif <je...@gmail.com> wrote on 09/18/2010 01:35:46 AM:
> >
> >> When using the Xerces 2.8.1 XML Schema API, the derived type from this
> >> schema:
> >>
> >> <?xml version="1.0" ?>
> >> <schema xmlns="http://www.w3.org/2001/XMLSchema"
> >>         targetNamespace="urn:webalo:try-extension"
> >>         xmlns:tns="urn:webalo:try-extension">
> >>
> >>     <element name="root" type="tns:Derived"/>
> >>
> >>     <complexType name="Base">
> >>         <sequence>
> >>             <element name="a" type="string"/>
> >>             <element name="b" type="string"/>
> >>         </sequence>
> >>     </complexType>
> >>
> >>     <complexType name="Derived">
> >>         <complexContent>
> >>             <extension base="tns:Base">
> >>                 <sequence>
> >>                     <element name="c" type="string"/>
> >>                     <element name="d" type="string"/>
> >>                     <element name="e" type="string"/>
> >>                 </sequence>
> >>             </extension>
> >>         </complexContent>
> >>     </complexType>
> >> </schema>
> >>
> >> is represented in that API as though it had content model:
> >>
> >>     <complexType name="Derived">
> >>    <sequence>
> >>           <sequence>
> >>             <element name="a" type="string"/>
> >>             <element name="b" type="string"/>
> >>           </sequence>
> >>      <sequence>
> >>             <element name="c" type="string"/>
> >>             <element name="d" type="string"/>
> >>             <element name="e" type="string"/>
> >>           </sequence>
> >>        </sequence>
> >>     </complexType>
> >>
> >> rather than what I would have naively thought:
> >>
> >>     <complexType name="Derived">
> >>    <sequence>
> >>             <element name="a" type="string"/>
> >>             <element name="b" type="string"/>
> >>             <element name="c" type="string"/>
> >>             <element name="d" type="string"/>
> >>             <element name="e" type="string"/>
> >>        </sequence>
> >>     </complexType>
> >>
> >> That is, the XSModelGroup representing the content of the type has two
> >> particles, each of which has a term which is an XSModelGroup, one with
> >> two and one with three particles.
> >>
> >> I have a test program to demonstrate this, if it is needed.
> >>
> >> Is this expected behavior and is it documented somewhere?
> >>
> >> What I've found elsewhere includes:
> >>
> >> a.  "A complex type which extends another does so by having additional
> >> content model particles at the end of the other definition's content
> >> model, or by having additional attribute declarations, or both."
> >>
> >> from XML Schema 1.0 Second Edition, section 2.2.1.3, which seems to
> >> suggest the form I had expected.
> >>
> >> b.  On the other hand, the infoset description, 3.4.1 which suggests
> >> there is a separate "base type definition" and "content type" which
> >> contains a content model, which could suggest the nested form found in
> >> my test.
> >>
> >> c.  The documentation for the XSComplexTypeDefinition.getParticle()
> >> method refers to "A particle for a mixed or element-only content
> >> model...".
> >>
> >> Thanks for any illumination.
> >>
> >> Jeff
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
> >> For additional commands, e-mail: j-users-help@xerces.apache.org

Re: Fw: Re: Representation of complex types derived by extension

Posted by Michael Glavassevich <mr...@ca.ibm.com>.
Have you actually tried this out? I wouldn't expect that the spec allows
you to do this except for the corner case where the base type is empty.

Thanks.

Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org

Michael Glavassevich <mr...@ca.ibm.com> wrote on 10/10/2010 05:20:32 PM:

> (Forwarding a message from Jeff Greif to the list that got lost in
> the moderation queue.)
>
> ----- Message from Jeff Greif <jg...@alumni.princeton.edu> on Tue,
> 28 Sep 2010 10:13:16 -0700 -----
>
> > Thanks very much, Michael.
> >
> > Related questions:
> >
> > If there is
> >
> > <extension base="X">
> >     <all>...</all>
> > </extension>
> >
> > I would expect that either X has no element content or a content model
> > of <all>, with some compatibility constraint between the <all>
> > particles of base and extension.  Since <sequence> must not have an
> > <all> child, presumably the {content type} must be modeled as a pair
> > containing a particle with {all} term.
> >
> > 1.  must X have empty element content or is something else possible?
> >
> > 2.  is the element-content part of {content type} represented as a
> > particle with a single {all} term?
> >
> > Jeff
> >
> > On Sat, Sep 18, 2010 at 2:19 PM, Michael Glavassevich
> > <mr...@ca.ibm.com> wrote:
> > > Hi Jeff,
> > >
> > > What you are getting from the XSModel is consistent with the
definition of
> > > the {content type} in the XML Schema 1.0 spec. For an extension it's
a
> > > sequence of two particles; a particle for the base content followed
by a
> > > particle containing the effective content [1] from the
> extension. Below the
> > > anchor [1] you'll see the formal definition in 3.2.3.
> > >
> > > Thanks.
> > >
> > > [1] http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/#key-exg
> > >
> > > Michael Glavassevich
> > > XML Parser Development
> > > IBM Toronto Lab
> > > E-mail: mrglavas@ca.ibm.com
> > > E-mail: mrglavas@apache.org
> > >
> > > Jeff Greif <je...@gmail.com> wrote on 09/18/2010 01:35:46 AM:
> > >
> > >> When using the Xerces 2.8.1 XML Schema API, the derived type from
this
> > >> schema:
> > >>
> > >> <?xml version="1.0" ?>
> > >> <schema xmlns="http://www.w3.org/2001/XMLSchema"
> > >>         targetNamespace="urn:webalo:try-extension"
> > >>         xmlns:tns="urn:webalo:try-extension">
> > >>
> > >>     <element name="root" type="tns:Derived"/>
> > >>
> > >>     <complexType name="Base">
> > >>         <sequence>
> > >>             <element name="a" type="string"/>
> > >>             <element name="b" type="string"/>
> > >>         </sequence>
> > >>     </complexType>
> > >>
> > >>     <complexType name="Derived">
> > >>         <complexContent>
> > >>             <extension base="tns:Base">
> > >>                 <sequence>
> > >>                     <element name="c" type="string"/>
> > >>                     <element name="d" type="string"/>
> > >>                     <element name="e" type="string"/>
> > >>                 </sequence>
> > >>             </extension>
> > >>         </complexContent>
> > >>     </complexType>
> > >> </schema>
> > >>
> > >> is represented in that API as though it had content model:
> > >>
> > >>     <complexType name="Derived">
> > >>    <sequence>
> > >>           <sequence>
> > >>             <element name="a" type="string"/>
> > >>             <element name="b" type="string"/>
> > >>           </sequence>
> > >>      <sequence>
> > >>             <element name="c" type="string"/>
> > >>             <element name="d" type="string"/>
> > >>             <element name="e" type="string"/>
> > >>           </sequence>
> > >>        </sequence>
> > >>     </complexType>
> > >>
> > >> rather than what I would have naively thought:
> > >>
> > >>     <complexType name="Derived">
> > >>    <sequence>
> > >>             <element name="a" type="string"/>
> > >>             <element name="b" type="string"/>
> > >>             <element name="c" type="string"/>
> > >>             <element name="d" type="string"/>
> > >>             <element name="e" type="string"/>
> > >>        </sequence>
> > >>     </complexType>
> > >>
> > >> That is, the XSModelGroup representing the content of the type has
two
> > >> particles, each of which has a term which is an XSModelGroup, one
with
> > >> two and one with three particles.
> > >>
> > >> I have a test program to demonstrate this, if it is needed.
> > >>
> > >> Is this expected behavior and is it documented somewhere?
> > >>
> > >> What I've found elsewhere includes:
> > >>
> > >> a.  "A complex type which extends another does so by having
additional
> > >> content model particles at the end of the other definition's content
> > >> model, or by having additional attribute declarations, or both."
> > >>
> > >> from XML Schema 1.0 Second Edition, section 2.2.1.3, which seems to
> > >> suggest the form I had expected.
> > >>
> > >> b.  On the other hand, the infoset description, 3.4.1 which suggests
> > >> there is a separate "base type definition" and "content type" which
> > >> contains a content model, which could suggest the nested form found
in
> > >> my test.
> > >>
> > >> c.  The documentation for the XSComplexTypeDefinition.getParticle()
> > >> method refers to "A particle for a mixed or element-only content
> > >> model...".
> > >>
> > >> Thanks for any illumination.
> > >>
> > >> Jeff
> > >>
> > >>
> > >>
---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
> > >> For additional commands, e-mail: j-users-help@xerces.apache.org