complexTypes versus elements

Discussion in 'XML' started by John LaRusic, Mar 21, 2007.

  1. John  LaRusic

    John LaRusic Guest

    Hi all,

    I'm fairly new to the world of schemas, but I have a question that I
    hope someone can help answer for me. I'm curious as to what the
    difference is between an element and a complexType?

    I know an element can be a complexType, so I guess what my issue is
    when I should define a complexType that's not contained in an element
    block, and when I should define a top-level element (what I mean by
    that is when I should define an element block right under the
    xs:schema node).

    I know I can define schemas in any of the following ways and that
    they're more or less the same schema:

    Schema1:
    <?xml version="1.0" encoding="utf-8" ?>
    <xs:schema targetNamespace="http://my.company.org/SampleSchema1"
    elementFormDefault="qualified"
    xmlns:my="http://my.company.org/SampleSchema1"
    xmlns:xs="http://www.w3.org/2001/XMLSchema">

    <xs:element name="StringField" type="xs:string"/>
    <xs:element name="IntegerField" nillable="true" type="xs:integer"/>
    <xs:element name="DoubleField" nillable="true" type="xs:double"/>
    <xs:element name="BooleanField" nillable="true" type="xs:boolean"/>

    <xs:element name="RootElement">
    <xs:complexType>
    <xs:sequence>
    <xs:element ref="my:StringField" />
    <xs:element ref="my:IntegerField" />
    <xs:element ref="my:DoubleField" />
    <xs:element ref="my:BooleanField" />
    </xs:sequence>
    </xs:complexType>
    </xs:element>

    </xs:schema>

    Schema 2:
    <?xml version="1.0" encoding="utf-8" ?>
    <xs:schema targetNamespace="http://my.company.org/SampleSchema2"
    elementFormDefault="qualified"
    xmlns:my="http://my.company.org/SampleSchema2"
    xmlns:xs="http://www.w3.org/2001/XMLSchema">

    <xs:element name="RootElement">
    <xs:complexType>
    <xs:sequence>
    <xs:element name="StringField" type="xs:string"/>
    <xs:element name="IntegerField" type="xs:integer"/>
    <xs:element name="DoubleField" type="xs:double"/>
    <xs:element name="BooleanField" type="xs:boolean"/>
    </xs:sequence>
    </xs:complexType>
    </xs:element>

    </xs:schema>

    Schema 3:
    <?xml version="1.0" encoding="utf-8" ?>
    <xs:schema targetNamespace="http://my.company.org/SampleSchema3"
    elementFormDefault="qualified"
    xmlns:my="http://my.company.org/SampleSchema3"
    xmlns:xs="http://www.w3.org/2001/XMLSchema">

    <xs:complexType name="RootElementType">
    <xs:sequence>
    <xs:element name="StringField" type="xs:string"/>
    <xs:element name="IntegerField" type="xs:integer"/>
    <xs:element name="DoubleField" type="xs:double"/>
    <xs:element name="BooleanField" type="xs:boolean"/>
    </xs:sequence>
    </xs:complexType>

    <xs:element name="RootElement" type="my:RootElementType" />

    </xs:schema>

    But which way is the most "correct"? My gut tells me to specify
    everything as complexType independent of any particular element, and
    only define top-level elements where I absolutely need them, but it
    seems most tools like to define everything as top-level elements.

    I hope this makes sense. It seems like there are lots of tutorials on
    how to create schemas, but I can't seem to find much on best practices
    in terms of how those schemas should be defined. Any help would be
    appreciated!

    Thank you,

    John LaRusic
    Developer, Atlantic Canada Opportunities Agency
     
    John LaRusic, Mar 21, 2007
    #1
    1. Advertising

  2. An element is the thing made up of a start-tag and an end-tag, which
    contains attributes and children. An element's value may have a type;
    that type may be a complex type which specifies those attributes and
    children.

    In your example, <RootElement> .... </RootElement> is an element which
    has a complex type that says it contains a specific sequence of other
    elements.
     
    Joseph Kesselman, Mar 21, 2007
    #2
    1. Advertising

  3. John LaRusic wrote:
    > I know an element can be a complexType


    No. An element is an element. It can have a type assigned by the schema;
    that type may either be a simple type or a complex type.

    > when I should define a complexType that's not contained in an element
    > block


    Do this when there will be several references to the same complex type,
    or when it's just clearer to describe it that way.

    If you've worked in C, this is the same question as when to use typedef
    versus when to just define the struct in-line. Or, in Java, when to use
    a stand-alone class definition versus when to use an anonymous class.
    There are times when you must give the type a name, there are times when
    you don't have to but want to, and there are times when it really is
    simplest to just do it where it's being used and not worry about it.
    Picking between these is a matter of style and judgement, and that comes
    with practice.

    If you really can't decide, give the type a name. That may not be the
    cleanest answer but it preserves all your options.

    > But which way is the most "correct"?


    Wrong question. Which is clearest, and which allows you to do what you
    intend to do later with this document type... and sometimes it honestly
    makes no difference.

    --
    Joe Kesselman / Beware the fury of a patient man. -- John Dryden
     
    Joseph Kesselman, Mar 21, 2007
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Larry
    Replies:
    0
    Views:
    452
    Larry
    Jun 4, 2004
  2. Larry
    Replies:
    1
    Views:
    424
    Yan Leshinsky
    Jun 10, 2004
  3. Replies:
    5
    Views:
    461
  4. sachin
    Replies:
    1
    Views:
    379
    Soren Kuula
    Dec 2, 2005
  5. Paul Butcher
    Replies:
    12
    Views:
    778
    Gary Wright
    Nov 28, 2007
Loading...

Share This Page