I may be misunderstanding how XMLBeans works, but I don't see any way
it's possible to add MTOM support without the data binding framework
being aware of it. In the XMLBeans case I'd think that the underlying
XML store would also need to be extended - otherwise it seems like
XMLBeans would insist on storing the data as base64 encoding, and would
also expect the data in that form on input and supply the data in that
form on output.
That's one of the drawback to the layering violations built into the
whole MTOM approach. See the earlier thread discussing this:
http://marc.theaimsgroup.com/?t=112131750700001&r=1&w=2
- Dennis
Davanum Srinivas wrote:
Ajith,
Could you walk the schema stuff as mentioned here:
http://mail-archives.apache.org/mod_mbox/xmlbeans-dev/200508.mbox/[EMAIL
PROTECTED]
"The way I would do it is: compile the schemas using the API
(XmlBeans.compileXmlBeans()) instead of using "scomp", get a
SchemaTypeSystem back and call .globalElements() and .globalTypes() on
it."
If we can extract enough info from the SchemaTypeSystem, we can store
it somehow and use it when we have to do MTOM.
thanks,
dims
On 9/1/05, Ajith Ranabahu <[EMAIL PROTECTED]> wrote:
Hi all,
As most of you know already XML Beans is used as one of the databinding
frameworks for Axis2. Although it was planned to add multiple framework
support, most of the work has been done only for XMLBeans and I guess it is
the practically usable one at the moment. However when integrating MTOM with
databinding we have slight problems.
1. Use of the Xmime schema extension. have a look at the following piece of
schema. (this is from
http://www.w3.org/TR/xml-media-types/)
<?xml version="1.0" ?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema";
xmlns:tns="
http://example.com/know-type";
xmlns:xmime="http://www.w3.org/2005/05/xmlmime";
targetNamespace="
http://example.com/know-type";>
<xs:import namespace="http://www.w3.org/2005/05/xmlmime";
schemaLocation="
http://www.w3.org/2005/05/xmlmime"/>
<xs:element name="JPEGPicture" type="xmime:base64Binary"
xmime:expectedContentTypes="image/jpeg" />
</xs:schema>
The xmime:expectedContentTypes attribute is the key here. As you can see
this attribute says what is the expected type of the binary content. The
right thing to do in the above case would be to generate the databind object
and have it return an image object as the result of data binding depending
on the expected content type. I'm not sure how much work has been done with
XMLBeans (or any of the other databinding frameworks for that matter)
regarding this but if the databinding framework is unaware of this, it
seriously limits our ability to handle MTOM with databinding!
2. Optimizing given text elements.Currently the code generated stubs can
work with byte arrays but sending content in optimized form is the problem.
XMLBeans is the one who sees that particular objects are base64 binary
(which can be optimized) but this information is burnt into the XMLBeans
generated classes and there's no way to propogate it to the OM tree (at
least I don't see a way yet). Hence when writing to the wire, we have no way
of saying which character items to optimize. We can do a global optimization
(all text nodes are optimized!) but i' m not sure whether that'll work at
all since optimization assumes the content to be bas64 encoded (in which
case it tries to decode!)
Any thoughts on how to deal with these problems ?
BTW I've cc'ed this to the XMLBeans list as well, perhaps the XBeans gurus
can shed some light on this issue :)
--
Ajith Ranabahu
