W3C home > Mailing lists > Public > xmlschema-dev@w3.org > April 2003

Re: List of union

From: Michael Marchegay <mmarcheg@optonline.net>
Date: Fri, 4 Apr 2003 16:28:59 -0500
Message-ID: <000b01c2faf1$351d2500$8c01a8c0@mendossa>
To: "Henry S. Thompson" <ht@cogsci.ed.ac.uk>
Cc: <xmlschema-dev@w3.org>

"Henry S. Thompson" <ht@cogsci.ed.ac.uk> writes:


>
> "Michael Marchegay" <mmarcheg@optonline.net> writes:
>
> > "Henry S. Thompson" <ht@cogsci.ed.ac.uk> writes:
> >
> > > "Michael Marchegay" <mmarcheg@optonline.net> writes:
> > >
> > > > My understanding of the concept of list, as defined in XML Schema
> > > > recommendation, would make me think that a list whose {item type
> > definition}
> > > > has the variety union is valid only if the union does not contain
any
> > simple
> > > > type definitions having the variety list among its {member type
> > > > definitions}.
> > > >
> > > > I looked in the XML Schema Part 1 and 2 for some text confirming
that,
> > but I
> > > > haven't found it.  I also looked in the archives of xmlschema-dev
list
> > for
> > > > an explanation, and I have found confirmation of my hypothesis, but
none
> > of
> > > > the answers refere to a clause stating it clearly.  Is this
restriction
> > > > explained somewhere in the recommendation?
> > >
> > > In Schema Component Constraint: Derivation Valid (Restriction, Simple)
[1]
> > >
> > >    "2 If the {variety} is list, then  all of the following must be
true:
> > >       2.1 The {item type definition} must have a {variety} of atomic
> > >       or union (in which case all the {member type definitions} must
> > >       be atomic)."
> >

Sorry to come back on this topic, but there is still a link between "Schema
Component Constraint: Derivation Valid (Restriction, Simple)" and "Schema
Component Constraint: Simple Type Definition Properties Correct" that I do
not understand.

"Schema Component Constraint: Simple Type Definition Properties Correct"
says:
4 If the {base type definition} is not the ·simple ur-type definition·, all
of the following must be true:
4.1 The definition must be a ·valid restriction· as defined in Derivation
Valid (Restriction, Simple) (§3.14.6).

The definition of base type definition is:
{base type definition}  The appropriate case among the following:
1 If the <restriction> alternative is chosen, then the type definition
·resolved· to by the ·actual value· of the base [attribute] of
<restriction>, if present, otherwise the type definition corresponding to
the <simpleType> among the [children] of <restriction>.
2 If the <list> or <union> alternative is chosen, then the ·simple ur-type
definition·.

Imagine that you have the following simple type definition:

<simpleType name="foo">
  <list>
    <simpleType>
      <union>
        <simpleType><list itemType="boolean"/><simpleType>
      </union>
    </simpleType>
  <list>
</simpleType>

The {base type definition} of foo is the ·simple ur-type definition·;
Derivation Valid (Restriction, Simple) is therefore not required; only
Schema Component Constraint: list of atomic is.  Schema Component
Constraint: list of atomic is verified (the {variety}of the {item type
definition} is union).

The simple type definition "foo" is then valid.

I can't find where I am wrong.

Michael

> > Thanks for the pointer.
> >
> > However, I am wondering if there isn't a partial redundancy - that can
> > confound the reader - between "Schema Component Constraint: Derivation
Valid
> > (Restriction, Simple)" and "Schema Component Constraint: list of
atomic":
> >
> > Schema Component Constraint: list of atomic [2]
> >     If {variety} is ·list·, then the {variety} of {item type definition}
> > ·must· be ·atomic· or ·union·.
>
> Redundant yes, but not wrong.
>
> ht
> --
>   Henry S. Thompson, HCRC Language Technology Group, University of
Edinburgh
>                       Half-time member of W3C Team
>      2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
>     Fax: (44) 131 650-4587, e-mail: ht@cogsci.ed.ac.uk
>      URL: http://www.ltg.ed.ac.uk/~ht/
>  [mail really from me _always_ has this .sig -- mail without it is forged
spam]
>
>
Received on Friday, 4 April 2003 16:29:26 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 11 January 2011 00:14:36 GMT