[lextypes] DLL proof of concept

[John Cowan]

Bob Foster scripsit:
> What constitutes proof of concept for DLL (or anything like it)?

The acronym "DLL" is already taken.  Jeni is using "dtl" as the file suffix,
so DTLL (or DLDL or DTLDL) seems more reasonable.

> - A reference implementation that accepts every valid definition and rejects
> every invalid definition (that is defined as required to be reported,
> according to the spec).

For sure.

> - An implementation that converts a valid definition to a form that allows
> it to be used with one or more existing schema languages such that a value
> is declared valid if and only if it conforms to the DLL definition.

In present practice this would mean providing an RNG datatype library interface.
See below.

> - A language-independent API specification and an implementation in one or
> more existing programming languages that allows, at a minimum, an
> application to ask, for any string value, whether it is a valid instance of
> a given datatype, and if so, to obtain the parse result. The API should be
> able to operate independent of validation.

Here's a somewhat oversimplified explanation of the RNG datatype
library interfaces.  In order to play nice with RNG validators, you
have to have implementations of the interfaces DatatypeLibraryFactory,
DatatypeLibrary, and Datatypes.  (There are additional interfaces
for implementing parameterized datatypes, streaming validators, and
context-sensitive datatypes that depend on the namespace-prefix map,
the base URI, or the DTD.)

A DatatypeLibraryFactory implementor has to recognize the URI(s) assigned
to the datatype library and return an implementor of DatatypeLibrary
specific to the URI.

A DatatypeLibrary implementor has to recognize a type name local-part
in the library and return an implementor of Datatype.

A Datatype implementor has to be able to do the following things:

1) Accept a string and report whether it matches this datatype.
This comes in two flavors: isValid returns a boolean, checkValid throws
an exception if not valid.

2) Accept a string and return a magic cookie called a value, such that
if two values are equal, the two strings used to create them represent
"the same thing".  A reasonable way, but not the only possible way, to
do this is to return a normalized version of the input string.

3) Compare two values for equality.

4) Return whether this datatype is context-sensitive.  If so, a
context object must be provided when checking for validity and when
creating a value.

5) Return the "IDness" of this datatype: whether it has the semantics
of an ID, IDREF, IDREFS, or none of these.

-- 
John Cowan  jcowan at reutershealth.com  www.reutershealth.com  www.ccil.org/~cowan
I come from under the hill, and under the hills and over the hills my paths
led. And through the air. I am he that walks unseen.  I am the clue-finder,
the web-cutter, the stinging fly. I was chosen for the lucky number.  --Bilbo