RE: Easier way to define enumerations

At 00/05/31 14:34 -0700, Biron,Paul V wrote:
> > -----Original Message-----
> > From: Martin J. Duerst [SMTP:duerst@w3.org]
> > Sent: Thursday, May 25, 2000 11:20 PM
> > To:   Biron,Paul V; 'petsa@US.IBM.com'
> > Cc:   www-xml-schema-comments@w3.org
> > Subject:      RE: Easier way to define enumerations
> >
> > I was aware of the whitespace problem as explained below,
> > but was not careful enough to think it through. Still,
> > I think it's easy to provide shortness while avoiding
> > the problem, e.g. by defining that xsd:enumeration
> > can have either a 'value' attribute (containing a single
> > value) or a 'valuelist' attribute (containing a list
> > of values, whitespace-separated). This would allow
> > to address values with and without whitespace.
> >
>Unfortunately, I think that adding the "valuelist" attribute would do little
>more than engender more comments that the schema spec is too complex and
>disconnected.

I'm absolutely not sure about this. There is a big difference
between syntactic sugar, which can be explained to everybody
by just putting two examples besides each other, and doesn't
affect the data model at all, but provides a great deal of
convenience, and on the other hand a feature that requires
subtile and confusing changes to the data model in all kinds
of places, that is difficult to explain, has a lot of corner
cases, and so on.


>As we are all aware, there are always tradeoffs in design of this sort,
>e.g., ease of authoring a schema vs. the complexity of the language itself.
>So some things (the case at hand being a good example) which might reduce
>the complexity of authoring an individual schema would cause the spec to
>bloat to the point where the average schema author would be able to tell how
>to create the schema that they intend.

The tradeoff is always there. But in this case, it's rather
clear that it's a small burden for spec authors, spec implementers,
and spec readers, and a big saving for schema writers.

Regards,   Martin.

Received on Thursday, 1 June 2000 01:47:41 UTC