axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sanjiva Weerawarana" <sanj...@watson.ibm.com>
Subject Re: Caching a message byte-for-byte
Date Wed, 13 Jun 2001 15:36:53 GMT
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
>
>


Mime
View raw message