OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-wsia message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: [wsrp-wsia] Jan F2F presentations


One action I took home from the f2f was to check CDATA support in some Web
Stacks as a way to send XML without having to encode it with entities (<
for < etc).

Both the .NET and Axis stacks accept xsd:string values encoded using
(multiple) CDATA sections, e.g. <![CDATA[try<this>out]]><![CDATA[& more
text]]>. I have a wsdl and a simple Java test, if anyone wants to check this
out on other SOAP stacks.

However, neither stack seems to support using this approach to encode/send
xsd:string values (I tried some rather long strings). For .NET and Axis, it
is possible to use an <s:any namespace="##other" /> to sent (multiple) CDATA
sections (by hand and they need to be wrapped in an element of course). But
this would seriously complicate receivers and the JAXRPC RI has problems
with raw anys, all at questionable performance gain.

From some casual searching on the Web, it seems most Web services just use
base64 or entity encoding to send HTML/XML over SOAP and the performance
benefits of CADATA anys or custom marshallers are likely to be very limited,
so I propose that we do not add support explicit for CDATA or markup ANYs to
1.0. [Anyone wishing to use CDATA to encode strings should verify receiver
stacks: I only tried Axis 1.0 and .NET framework 1 receivers.]

It seems the WS-I (www.ws-i.org) will add support for Attachments to the
basic profile: http://www.theregister.co.uk/content/53/29084.html and I
propose we kick off our attachments activity in a month or so once the wsrp
1.0 dust settles some.

Also, at last week's JSR 168 meeting, we discussed marking MIME types to
indicate if the MIME markup was a fragment or a full document. It would be
possible to add a parameter to MIME Content Types, e.g. ContentType:
text/html; fragment="true". While such parameters are supposed to be
predefined for a type (in an RFC?), MIME processors are required to ignore
any parameters they do not understand. We decided not to pursue this for the
(first) Portlet JSR, but this could be considered in WSRP (post 1.0, and
WSRP attachments could even add further "; parameter=value" parameters).
Something for the markup sub-group to consider?

regards,
Andre


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC