I discussed this offline with Murata-san, and I think I now understand his
concerns.
We can divide datatype library context info into two categories:
1) Information that is the same for all elements in a document (let's call
this document-level context).
2) Information that may vary from element to element within a single
document (let's call this element-level context).
For document-level context, I think we have agreement that we can leave this
open-ended. Also it doesn't require anything in the formal semantics: we
can regard the datatypeAllows and datatypeEqual functions as being methods
on the document, and hence implicitly having access to arbitrary
document-level context.
However, element-level context cannot be swept under the carpet in this way.
Element-level context cannot be ignored by the formal semantics. Clearly, we
have at least to support namespace map.
I believe we also have to support base URI information (which can vary from
element to element). RELAX NG schemas should themselves be instances of our
data model. Since <include> and <externalRef> need information about the
base URI, this has to be in our data model. (This is independent of the
xml:base issue; we need base URI information, regardless of whether or not
the base URI info is affected by xml:base attributes.)
I think the issue is simply this: should the element-level context used by a
datatype library be allowed to contain anything other than the namespace map
and base URI? Murata-san believes not (correct me if I have misrepresented
your position). I am not yet convinced that it is essential to so limit it
(though I can certainly live with it being so limited).
James
----- Original Message -----
From: "James Clark" <>
To: "RELAX NG Mailing List" <>
Sent: Monday, June 18, 2001 1:06 PM
Subject: Context info for datatype libraries
> Another aspect of this issue to bear in mind is that the semantics of
anyURI
> may depend on xml:base and on the base URI of the document as a whole
(which
> is not a syntactic part of the document). If it turns out that anyURI
does
> not depend on this, then it is certainly conceivable that one would have a
> datatype that did. In general, there may be arbitrary metadata associated
> with a document, and datatype libraries may want to have datatypes that
are
> interpreted relative to that metadata. I therefore don't think we can ro
> should try to completely nail down what the context is for datatype
> libraries.
>
> At the moment, in our datatype, elements have a name, a namespace map,
> attributes and children. I propose to change this to say that they have a
> context rather than a namespace map; the context includes a mapping from
> prefixes to namespace URIs but may have other stuff too. We don't place
any
> requirements on the context beyond its containing the prefix to namespace
> URI mapping. Our semantics doesn't need to manipulate the context; it
just
> needs to show how it gets passed around.
>
> James
>
>
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to:
>
>
>
