[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Datatype interface for RELAX NG
> > One more comment. I am concerned about the efficiency when processing
> > base64Binary or hexBinary. It seems quite possible that applications
will
> > have extremely large content with these types (many megabytes). It would
be
> > desirable for the interface to allowed validating these types without
> > keeping the entire instance of the datatype in memory.
>
> How important is this capability?
Hard to say. It depends how frequently documents will contain instances of
simple types with very long lexical representations.
> I thought about this at the very beginning of the development (of Sun
> XML Datatypes Library). But I abandoned this goal.
>
> - Firstly, this change makes base64/hex validators stateful objects.
>
> - All other grammar primitives (ChoicePattern, etc) are stateless and
> therefore can be shared and reused; stateful objects can't. Sharing
> a grammar among multiple threads seemed important.
>
> - OTOH, changing validators to the factory objects that creates actual
> stateful validators seemed cumbersome to me.
This need not be cumbersome for clients of the library. You add a method to
DataType:
ValueIterator createValueIterator();
Then create a ValueIterator interface roughly like this:
interface ValueIterator {
boolean characters(char[] buf, int start, int len, boolean isLast);
}
Clients that need this capability can have it. Those that don't can use the
existing, simpler interface.
As well as base64Binary and hexBinary, this would be useful for string.
> - Secondly, it also affects the core validation code, which is another
> thing I don't want.
It certainly has a complexity cost for the code.
> - Thirdly, if the performance is really a problem, you can always skip
> validating that specific part by modifying your grammar a little bit.
I don't think that's an option in many cases. It is also useful for string
type; even with a pattern facet there is no need for the entire string to be
in memory.
James
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC