Re: Context info for datatype libraries

[MURATA Makoto <mura034@attglobal.net>]

Here I try to summarize differences between James and me.  This message 
is also relevant to Kawaguchi-san's datatype interface.

- Are datatype libraries allowed to access information external to 
  documents?

Both James and I believe that they should be allowed.  I believe that 
other members of the TC also agree.

- Which information within documents is useful for datatype libaries?

The TC has agreed that prefix-namespace mappings and base URIs 
are useful.

We have also considered other thing as below:

	- declaration of notations,
 	- declaration of unparsed entities, and 
	- the XML version number, 

In fact, Kawaguchi-san's interface for datatype implementations covers
the first and second (to be precise, names of notations/entities), but 
does not cover the third.

- Which information is useful for datatype libraries and is NOT 
  shared by all elements/attributes?

We have considered 

	- base URIs (because of xml:base), and
	- xml:lang

Kawaguchi-san's interface for datatype implementations does not 
cover them.

- Do we want to list such useful information in our spec or 
  datatype libary interface?

Here James and I disagree.  James believes that the spec should not
have such a list, since it increases the complexity of the spec.  I
believe that we should try to enumerate such information for two 
reasons.  First, there are only a few.  Second, implementors will 
not do anything, unless they see a list in the spec or a standard 
interface.

- Do we force the RELAX NG validator to pass information to 
datatype libraries or do we merely allow it to do so?

James does not want to force such information passing.  I don't
either, although James appears to believe I do.

- Do we want to explicitly disallow other information?

James does not.  But I do, since I would like to have a clear boundary between the
RELAX NG and datatypes.  If it is not realistic to make a short and sufficient 
list, I will change my mind.

> If you allow access to arbitrary external information, I see no point in
> restricting access to information about the document.  An external
> library can just use the base URI to load the document again and thus
> get access to arbitrary information about the document.

First, layering is important even if it is not possible to completely
hide information in one layer from another layer.  Second, when the
XML document is given as an input stream, external libraries cannot load the
document again and thus James' argument does not apply.

> I don't want to force RELAX NG implementations to provide information
> such as ENTITY and NOTATION declarations; if they don't want to support
> datatype libraries that need such information, then they shouldn't have
> to provide it.  

Me too.  I do not want to force RELAX NG implementations to provide
information such as ENTITY and NOTATION declarations.  However, I think 
that it is a nice thing to add 

	String getBaseURI();
	String getXMLVersionNumber();
	String getLanguage();

to ValidationContext.java of Kawaguchi-san's interface and a few words about them 
in the language spec.  If an RELAX NG implementation choose not to implement them, 
they can return null or throw exceptions.

>On the other hand I don't want to prevent RELAX NG
> implementations from providing datatype libraries with whatever
> document-level context they require.

I certainly hope to do so.

> I am also very concerned about the complexity of the spec.  Getting in
> to enumerating things like version number and notations and unparsed
> entities seems to me to add a lot of complexity.  I think it should be
> left as a matter of negotiation between RELAX NG implementations and
> datatype library providers.

In the XML Information Set specification, the document has only a few
information items.  I do not believe that considering them adds any
complexity.  To the contrary, I think that enumerating things help
developers.  If we do not provide any info, developers of RELAX NG
will not support the XML version for example.

Cheers,

Makoto