RE: On constraining/validating datatypes

I support Steven's separation of the "data type" problem into several
issues.  In fact, I think it is appropriate to divide it further, and
this may help to separate the work into the parts that need to be done
now versus those that can be deferred.

1.	How is the type of an element identified.  That is, the specific
syntax that says "this element is of type x".  This needs to address the
fact that several types are further qualified (such as the number of
digits for the proposed DECIMAL type).

2.	From what namespace do types come?  Is it a closed set, or an
extensible one?  If extensible, how and by whom?

3.	If a set is defined by us, is it part of the language
specification, or a standard library?

4.	Are data types the same as element types?  Notations?  Some new
beast?

Answering the questions above solves the problem of unambiguously
attaching a data type to an element.

We could go further and ask How do we validate that the element contains
the claimed type?  In what language are the validations expressed? How
do we distribute the parsers and validators? How does validation
interact with the issue of element sub-classing? (Strongly, in my
opinion.)

The immediate needs I am hearing from customers is only to solve the
first set. That is, they simply need a way for an author of an element
to communicate a subtype of PCDATA and a notation.  They will have
parsers for the notations they care about.  They are not presently
interested in any general-purpose validation, enforcement, or parsing
language.

I hope this is helpful.

--Andrew Layman
   AndrewL@microsoft.com

Received on Thursday, 22 May 1997 20:03:51 UTC