Kohsuke Kawaguchi wrote:
> Paul Sandoz wrote:
>
>> I think this makes good sense.
>>
>> It does mean that XOP-based writer and reader would have to delegate
>> lots of methods (unless SJSXP supported those methods directly).
>
>
> I think XOP-based reader needs to hook into a lot of methods anyway, so
> I think that side is OK. For example, even a simple method like
>
> getNamespaceURI()
>
> has to be changed not to return 'xop' for "xop:Include". On the writer
> side you are right. The writeStartElement() method can just pass
> through, but the proposed modification will require a delegation.
>
>
> If it turns out to be a real cost, perhaps we can write one version that
> extends the Zephyr class, another that delegates? We can try to use the
> former first, and if it fails to load correctly, we can resort to the
> latter?
>
Yes. I think this is a good approach. We have the flexibility to change
implementations later.
> Or eventually would it make sense to ask the parser team to support
> these things? If XOP is an infoset encoding, it makes sense to me to
> have them handle it --- they might be able to do it more efficiently
> than we do.
>
I think that should be a long term goal in line with extending the StAX
API to support data type encoding/decoding in addition to other useful
utility methods.
Paul.
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109