Re: Datatype interface for RELAX NG (updated)

[James Clark <jjc@jclark.com>]

Comments on the interface:

1.  Since its datatypeLibrary not dataTypelibrary, the names of classes
should use Datatype not DataType.

2. I don't think Datatype.check() needs to be optional.  If implementations
can't provide detailed information about why a match fails they can just
throw an uninformayive DatatypeException.

3. The protected members of DataTypeException are evil. Make them private
and final and add accessors.

4. Add a constructor with no arguments to DataTypeException to deal with 2.

5. I don't think the content member of DataTypeException is necessary.  The
caller knows this already.

6. displayName on DataType is not necessary.  The caller knows what the name
of the datatype is, since they used the name to create it with
createDataTypeBuilder or getType.  Conceptually, the datatype library is a
mapping from local names to datatypes.  The name isn't part of the datatype.
The object representing a <data> pattern should store the name in addition
to the DataType object.

7. Return value of characters on DataTypeStreamingValidator is unclear.  For
example, if we have a streaming validator for int, and the first call to
characters passes "+", what does characters() return?  It should return true
because it no error has been detected. isValid() should be called only when
you have finished accumulating the value.  Thus characters() does not return
what isValid would return after processing the fragment.  For this reason, I
think isValid() should be renamed to something like finish() or end().

8. How does DatatypeStreamingValidator provide the diagnosis information
that you get from the DatatypeException? This should be possible, index in
DatatypeException should be an index into the entire string.

9. Get rid of reset() on DatatypeStreamingValidator.  It's an
over-optimization and complicates the semantics of the object.

10. On ValidationContext, I think if we support isUnparsedEntity(), we
should also support isNotation(). (SAX supports both.)

11. We need to think about how instances of DatatypeLibrary get created.
Ideally, what we want is that an implementor of a DatatypeLibrary provides
their datatype library as a jar file, and all the user has to do is put that
jar file in the CLASSPATH, and it should just work.  If they have multiple
jar files for different libraries, they should put them all in the CLASSPATH
and it should just work.  If their are multiple implementations of the same
library, then the one earlier in the CLASSPATH should one.  I think we
should probably use the "Service Provider" approach.  See

http://java.sun.com/j2se/1.3/docs/guide/jar/jar.html#Service%20Provider

JAXP 1.1 also uses this to create parsers and transformers. Suppose I have a
class com.thaiopensource.datatype.xsd.DatatypeLibraryImpl implementing of
org.relaxng.datatype.DatatypeLibrary.  Then I add to my jar file a file

  META-INF/services/org.relaxng.datatype.DatatypeLibrary

containing the line:

  com.thaiopensource.datatype.xsd.DatatypeLibraryImpl

To support this the DatatypeLibrary needs to contain information about the
datatypeLibrary URI.  Maybe a getURI method? We also need to require that
DatatypeLibrary implementations have a zero argument constructor.

We should then provide a helper class that finds the library for a
particular URI.

12. DataType needs a valueHashCode() method consistent with sameValue() in
order to implement keys.

James