Re: conformance and datatype libraries

> 
> > Either the specification should state that a relax ng with datatypes not conforming
> > to the datatype library which is claimed to be supported is incorrect, and then
> 
> I think that this is exactly what the specification does in the last para of 4.16.  
> A schema is incorrect if it references to a non-existent datatype or
> specify incorrect parameters in some datatype library.  If a RELAX NG
> validator supports this datatype library, it is required to report that
> this schema is invalid.  Am I missing something again?

  1) In my opinion, there is no provision in the specification to check for these
  constraints.

  : 6.2.8. data and value pattern
  : ...
  : A datatype library provides two services.
  : 
  :     * It can determine whether a string is a legal representation
  :     of a datatype. This service accepts a list of zero or more
  :     parameters. For example, a string datatype might have a parameter
  :     specifying the length of a string. The datatype library determines
  :     what parameters are applicable for each datatype.
  : 
  :     * It can determine whether two strings represent the same value
  :     of a datatype. This service does not have any parameters.

  There is no service in a datatype library that helps check for these constraints.

  2) Section 4.16 does not specify whether a schema with a value that is not allowed
  by its datatype is valid or not.

These issues are not nitpicking. I would not raise my voice if they were.

The problem for me is that I am trying to realize the correct point(s) to plug
datatypeLibraries into Relax NG validator. And it turns out that:

- the current specification is underspecified and contradictory (issue with the value
  and  inability of a datatypeLibrary to check whether a type is valid);

- an approach when a datatype library has only one connection -- at validation time --
  is clean but defers checks till actual data is met;

- an approach when a datatype library is checked during parsing would work if
  datatypeLibrary definition was changed to provide the corresponding service.
  However, that means  that a datatype is no more a qname,
  but an opaque object, which -- and not its library -- provides methods 
  datatypeAllows and datatypeEqual.

My impression is that, despite the claim of extensibility, the current
specification is tailored towards use of a limited predefined set of datatype
libraries. 

The Datatype Library Java API is good in the sense that it follows the latter
approach. But the specification is contradictory for anyone who is going to implement
extensible datatypes. 

David Tolpin
http://davidashen.net/