I think this is a good thing for a RELAX NG processor to do, but I'm not
sure the spec needs to say anything. I don't think I want to mandate any
particular recovery behavior. Treating it as a string may be fine in some
environments, but in other environments it may be more appropriate to give
an error. Or it might be a nice feature if a processor supported datatype
mapping, which allowed unknown datatypes to be mapped onto supported
datatypes, with or without an error or warning.
----- Original Message -----
From: "Kohsuke KAWAGUCHI" <>
To: <>
Sent: Friday, July 27, 2001 2:02 AM
Subject: Re: Fallback mechanism for the datatype
>
> > Also, it would be nice if any valid document is accepted in the fallback
> > mode. (We can't help but accept invalid documents)
> >
> > To achieve that, we just need to abandon key/keyref check for
> > unavailable datatypes.
>
> I think I need to explain this better... let me try again.
>
> Assume a schema processor A, which do recognizes the
> "my:secret:datatype:library" library. Assume another schema processor B,
> which fails to resolve "my:secret:datatype:library".
>
> It's nice if the fallback mode achieves the following property:
>
> If a document is accepted by A, it is always accepted by B.
>
>
>
> To do that, at least we need to abandon key/keyref check; we can't check:
>
> - whether two keys are colliding each other
> - whether there is a key for every keyref.
>
>
> Also, I found that it needs to handle <except> pattern with unknown
> <data/> differently. So that
>
> <data type="string">
> <except>
> <data type="foo" datatypeLibrary="unknown"/>
> </except>
> </data>
>
> would be treated as:
>
> <data type="string">
> <except>
> <notAllowed/>
> </except>
> </data>
>
>
> regards,
> --
> Kohsuke KAWAGUCHI +1 650 786 0721
> Sun Microsystems
>
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to:
>
>
>
