OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ANN: XML Schema: DOs and DON'Ts

----- Original Message -----
From: "Kohsuke KAWAGUCHI" <kohsukekawaguchi@yahoo.com>
To: "Jeff Lowery" <jlowery@scenicsoft.com>; "Eddie Robertsson"
<eddie@allette.com.au>; <xml-dev@lists.xml.org>
Sent: Thursday, May 17, 2001 9:17 PM
Subject: Re: ANN: XML Schema: DOs and DON'Ts

> > > I understand that you can't believe what I said. But the fact is, the
> > > spec explicitly prohibits this. If you have some time and plenty
> > > of patience, see the spec:
> > > http://www.w3.org/TR/xmlschema-1/#rcase-Recurse
> >
> > Looking at this, I see rules for model groups, not enumeration facets. I
> > don't believe enumerations facets are order-dependent, if that's your
> > Restriction of enumerations is allowed, and such appears in the Schema
> > Schemas (Normative) section of the Recommendation.
> Maybe I'm missing something big, but when did we talk about restriction
> of simple type by enumerations?
> I think we are talking about restriction of <all> particle.

We are. The example given is;
Base type:
  <xs:element name="a" />
  <xs:element name="b" />
  <xs:element name="c" />

New type derived by restriction:
  <xs:element name="b" />
  <xs:element name="a" />

and you are correct, it's *not* a valid restriction because in restriction
you *must* list the particles in the same order in the derived type as they
were in the base type. Reversing the order of the element decls for a and b
in this case is what causes the problem.

I still don't really get the thrust of the document though... I think that
rather than saying 'use model groups instead of complex types' ( which is,
in fact, impossible ) you want to say 'use anonymous complex types instead
of named complex types' and possibly 'do not use type inheritance'. As
stated earlier I don't agree with either of these positions but I think they
more accurately capture the direction you are taking.

Talking about model groups the way you do is as confusing as the way you
talk about attribute groups, to me, at least because you can only use model
groups as part of complex types.