Re: Clarification on enumerations

Basically, I agree with the point you are making.  There is real value in 
having lexical constraints on non-string types.  I'm just pointing out 
that there is also complexity and subtlety associated with achieving that 
value.  On balance, I would have avoided that complexity for Schemas 
version 1.0, but I can certainly see the other side of the equation. 
Still, it's very difficult to give a neat exposition of the value space of 
such types, and that makes me nervous.  Thanks!

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------







Jeni Tennison <jeni@jenitennison.com>
07/23/2002 05:28 AM
Please respond to Jeni Tennison

 
        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>
        Subject:        Re: Clarification on enumerations


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 13:59:50 UTC