Actually, if you use DOM you can't get it back either .. the
order of attributes is not specified; its impl defined. I
personally don't think this is a problem, as long as Axis
has some way for a handler (or whatever) to intercept at a
lower level too (ala the EnvelopeEditor stuff in Apache SOAP).
Sanjiva.
----- Original Message -----
From: "Doug Davis" <dug@us.ibm.com>
To: <axis-dev@xml.apache.org>
Sent: Wednesday, June 13, 2001 10:48 AM
Subject: Re: Caching a message byte-for-byte
> I think you need to verify this with Yuhichi because I think they
> ran into a problem a long time ago where their XML parser
> wasn't keeping whitespaces and it was throwing off the
> digsig verification process.
>
> So, you're telling us that if you use Sax its impossible to
> get the XML message byte for byte as it was sent from the
> client? Doesn't seem quite right.
>
> -Dug
>
>
> Glen Daniels <gdaniels@macromedia.com> on 06/13/2001 10:28:11 AM
>
> Please respond to axis-dev@xml.apache.org
>
> To: "Axis-Dev (E-mail)" <axis-dev@xml.apache.org>
> cc:
> Subject: Caching a message byte-for-byte
>
>
>
>
> I just want to codify and confirm some discussion which happened on IRC
> yesterday.
>
> Storing a message as a series of SAX events will NOT be able to generate
> exactly the same sequence of bytes which originally constitued the
message.
> In particular, consider:
>
> <element xmlns:ns1="url1" attr1="val" xmlns:ns2="url2"/>
>
> Because SAX splits out the namespace decls into a separate event, there is
> no way to reconstruct the attributes of this element in the correct order,
> and also there is no way to record the fact that there is extra whitespace
> between attr1 and ns2.
>
> Thus, the only way we could see to get the original bytes if you need them
> would be to tee the actual bytestream and cache it. Which we're not, I
> believe, going to make a high-priority feature.
>
> DigSig, which has been the oft-used example of needing this, actually only
> requires a DOM model of the message, in which inter-element whitespace and
> attribute ordering are not significant.
>
> We do still want to have the option of keeping the SAX events around and
> recreating the XML in a semantically equivalent form, without lossage (the
> "000" -> "0" example), but byte-for-byte isn't really gonna happen.
>
> Glen Daniels
> Macromedia
> http://www.macromedia.com/
> Building cool stuff for web developers
>
>
|