--On 05 September 2001 14:44 -0700 Kohsuke KAWAGUCHI
<> wrote:
>
> The current draft says:
>> the pattern in the attribute element does not contain data or value
>> elements with context-dependent datatypes (the datatypes defined in
>> this specification are all context-dependent)
>
> but I guess it's hard for an implementation to enforce this, considering
> the fact that it allows arbitrary datatype library. At least we can't do
> this under the current datatype interface.
There's a trick you can use. Call the datatype library to validate the
default value. If the datatype library tries to access the context, then
have the context throw an exception. The caller then catches the exception
and gives an error to the application. Maybe we should phrase the
restriction differently:
- checking that that default value matches the pattern in the attribute
element must not require access to the context
Alternatively we can extend the datatype interface. If the datatype says
it's context independent then you can pass a null argument for the context.
Or maybe we have an additional method for checking the value of a datatype
that doesn't supply a context argument and may throw a
ContextRequiredException.
> Also what does "context-dependent" exactly mean? If I implement a
> datatype that checks if a timestamp belongs to the past, is it
> context-dependent?
It means that the datatypeAllows function for the datatype gives different
answers for some set of arguments that differ only in the context argument.
> I think it's safe to drop this constraint, especially because I
> understand that the resulting infoset is not necessarily valid.
I don't think we can drop this constraint unless we also drop the
constraint that the default-value matches the pattern.
James
