On 6/28/05, Shankar Unni (JIRA) <axis-dev@ws.apache.org> wrote:
>     [ 
> http://issues.apache.org/jira/browse/AXIS-2025?page=comments#action_12314621 ]
> 
> Shankar Unni commented on AXIS-2025:
> ------------------------------------
> 
> > With less jumping up and down and more providing of a patch, I would think 
> > that this
> > is a valid bug and be inclined to apply the patch.
> 
> I apologize. It's been a bit frustrating dealing with this bug.
> 
> Yes, Axis is a SOAP processor, and not an RPC mechanism. And Yes, SOAP lays 
> out rules for what is a valid message. The question is what happens when you 
> try to implement an RPC mechanism on top of SOAP - the bug is in *that* 
> layer, which the Axis library also supports.

[venkat] So, is this a question for SOAP spec?

> So yes, it's a larger issue - *if* you're building an RPC layer on top of the 
> SOAP infrastructure, and given the restrictions in the SOAP layer's use of 
> <xsd:string>, how do you safely transport Strings in general.
> 
> This is definitely an interoperability issue. But in the meantime, is there 
> some other type that can be used to transport such strings? For instance, is 
> it possible to use a custom type to map Strings into SOAP (i.e. avoid 
> <xsd:string>)? Would such a thing be portable? I could see a custom mapping 
> to some base64-type representation for the string body, but both sides need 
> to agree that it's a String, and have it be mapped back to a String upon 
> decoding.
> 
> Even if ready-made solutions are not available, I would greatly appreciate 
> some hints or suggestions on how this can be *reasonably* handled - something 
> that doesn't involve trying to hunt down every string in every interface and 
> possibly convert them to attachments, or hand-encoding and decoding every 
> string everywhere..  (I.e. reasonable workarounds / suggestions would be a 
> great help!)
> 

[venkat] How about making your service method and client code a bit
smarter, doing a scan of strings and escaping / unescaping the invalid
characters before pasing it onto Axis? Infact Axis does the same thing
- scanning each character in every string. For me, its the question of
who should handle the xml-invalid characters and I think the
application code is the right place to do it, until the
interoperability specs change their mind and put the onus onto the
SOAP processors.

Otherwise, can you suggest a reasonable patch for Axis code for
"safely transporting" the invalid characters?

-- venkat

Reply via email to