W3C home > Mailing lists > Public > www-xml-schema-comments@w3.org > April to June 2000

RE: Easier way to define enumerations

From: <Noah_Mendelsohn@lotus.com>
Date: Sat, 3 Jun 2000 14:47:38 -0400
To: www-xml-schema-comments@w3.org
Message-ID: <OFCD710CE0.94B4AEA1-ON852568F3.00663B38@lotus.com>

I'm not sure what the best tradeoff is on this one, but I think the
downside for users is seeing two schemas that appear to use different
mechanisms, and having to do research to determine that they in fact mean
the same thing.  There is also a bit of added complexity not only for
schema processors, but for tools like XSL stylesheets that might be used to
transform or manipulate schemas.   Indeed, my main concern with the
proposal is that I generally prefer to see markup used to represent
structure, exactly because tools like XSL can easily understand it.  If I
want to import a schema into my database using the current syntax, it's
trivial for me to get at the enumeration values using standard XML
mechanisms.  If there are two representations, I need code for both..

On a related subject, I think it's true that some of Martin's use cases
involved rather long lists of enumerations (hundreds? thousands?)  In all
kinds of subtle ways, implementations get tuned to expected use cases.  So,
for example, most web server environments would be completely messed up if
you told them that there were a million URI schemas (like HTTP:) that they
had to understand, but dealing with millions of URI's is a given.  Neither
is logically precluded by web architecture or specifications.  Similarly,
if we expect users to create extremely large enumerations (using whatever
syntax), then we should warn implementors.  I am not sure that most
implementors of schema processors are necessarily using hash tables or
other mechanisms that one would use on large enumerations (and which can
have a cost or require special casing for the common case of smaller
lists.)  Martin:  regardless of syntax, what would be the cardinality of
the larger enumerations that you anticipate?  If it's big, we should warn

Noah Mendelsohn                                    Voice: 1-617-693-4036
Lotus Development Corp.                            Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142

                    Rick JELLIFFE                                                                                                
                    <ricko@geotempo.com>                To:     www-xml-schema-comments@w3.org                                   
                    Sent by:                            cc:     (bcc: Noah Mendelsohn/CAM/Lotus)                                 
                    www-xml-schema-comments-requ        Subject:     RE: Easier way to define enumerations                       
                    06/01/00 03:55 AM                                                                                            

> At 00/05/31 14:34 -0700, Biron,Paul V wrote:

> >Unfortunately, I think that adding the "valuelist" attribute would do
> >more than engender more comments that the schema spec is too complex and
> >disconnected.

Users often only care about complexity when it is difficult to do
something that they thing should be simple to do, in particular when
that complexity is a cost to them--when they have to wade through
unnecessary options or understand unrelated concepts.

Not having alternative forms is exactly the kind of thing that may cause
a user to be more short-tempered with the plethora of other features.

In particular, they may consider (as I do) these lexical/token issues to
be a more fundamental issue for a schema language to address than the
delicate intricacies of atomic data typing.  The current drafts seem to
assume that raw XML solves all lexical/tokenizing issues, but that is
far from the case.

Rick Jelliffe
Received on Sunday, 4 June 2000 17:50:20 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:08:47 UTC