W3C home > Mailing lists > Public > xmlschema-dev@w3.org > July 2002

Re: Clarification on enumerations

From: Jeni Tennison <jeni@jenitennison.com>
Date: Tue, 23 Jul 2002 10:28:09 +0100
Message-ID: <801460617226.20020723102809@jenitennison.com>
To: noah_mendelsohn@us.ibm.com
CC: Eric van der Vlist <vdv@dyomedea.com>, Michael Leditschke <mike@ammd.com.au>, "Biron,Paul V" <Paul.V.Biron@kp.org>, <xmlschema-dev@w3.org>

Hi Noah,

> I am one of those who agree (and agreed) with Paul that having
> constraints at two levels is messy in the type system. It's not too
> bad when doing validation of character strings. It's very difficult
> if you try to build an API that lets programs synthesize documents
> using values.

That's a fair point. However, I'd argue that there is a significant
subset of markup languages in which the lexical representation of a
value is important to the people using that markup language -- people
are always wanting to specify "exactly three decimal spaces" or "in
UTC". I think that document synthesis would be better served by
tackling the problem of giving people control over the lexical
representations used in the documents they generate rather than by
pretending that the lexical representation of a value doesn't matter.

For example, rather than giving people the API:

  void set(int)

why not use:

  void set(int, string?)

where the second argument is a pattern for the numerical format that
should be used (e.g. as in java.text.DecimalFormat).

If the pattern that someone uses in the API creates a lexical
representation that isn't valid against the regular expression as
declared in the schema, then that's their problem (just as it would be
if the string value that they supplied didn't match the
schema-specified pattern).

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/
Received on Tuesday, 23 July 2002 05:28:11 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:55:57 UTC