Date: 2005-03-09T20:52:53
Editor: EranChinthaka
Wiki: Apache Web Services Wiki
Page: ChatAgenda/20050310/ChatLog
URL: http://wiki.apache.org/ws/ChatAgenda/20050310/ChatLog
no comment
New Page:
Main topics of the day was MTOM and data binding ...
-- EranChinthaka
[wiki:ChatAgenda Other Chats]
{{{
[3/10/2005 9:03 AM] <Srinath_> ?
[3/10/2005 9:04 AM] <Deepal> hi GM/GE all
[3/10/2005 9:04 AM] <Srinath_> all are sleep ? :)
[3/10/2005 9:04 AM] <Deepal> there is nothing in the agenda to discuss
[3/10/2005 9:04 AM] <Srinath_> shall we discuss the encoding ?
[3/10/2005 9:05 AM] <Srinath_> dasrath how is the new about encoding?
[3/10/2005 9:06 AM] <sanjiva> hi guys
[3/10/2005 9:06 AM] =-= Srinath_ has changed the topic to ``mtom & encoding''
[3/10/2005 9:06 AM] <dasarath> well
[3/10/2005 9:06 AM] <Srinath_> :)
[3/10/2005 9:07 AM] <Chinthaka_> Thilina has commited a prototype of MTOM in to
the scratch area
[3/10/2005 9:07 AM] <Deepal> are we going to intregare that to main tree ?
[3/10/2005 9:07 AM] <dasarath> we need to sort out the problem b/w OM & xmlbeans
[3/10/2005 9:09 AM] -->| thilina ([EMAIL PROTECTED]) has joined #apache-axis
[3/10/2005 9:09 AM] <Chinthaka_> what is the problem Dasarath ?
[3/10/2005 9:09 AM] <Deepal> BTW dasrath wt are the problems b/w om and xmlbeans
[3/10/2005 9:09 AM] <Srinath_> deepal:not untill we discuss it enpough
[3/10/2005 9:09 AM] <Deepal> ok , sure
[3/10/2005 9:09 AM] <thilina> hi
[3/10/2005 9:09 AM] <dasarath> for data binding we need to layer OM and
xmlbeans on top of one another at different times
[3/10/2005 9:10 AM] <alek_s> hi
[3/10/2005 9:10 AM] <Srinath_> hi alek
[3/10/2005 9:11 AM] <dasarath> however at present there are some semantic
differences b/w XMLStreamReader impl in
[3/10/2005 9:11 AM] <dasarath> OM and xmlbeans
[3/10/2005 9:11 AM] <alek_s> Thilina: very nice documentation for yout MTOM
impl!
[3/10/2005 9:11 AM] <Chinthaka_> that is a problem of interpreting the spec, I
think
[3/10/2005 9:11 AM] <alek_s> semantic differences?
[3/10/2005 9:11 AM] <Chinthaka_> I will be posting that question to the StAX
mailing list anyway
[3/10/2005 9:12 AM] <thilina> alek :
[3/10/2005 9:12 AM] <thilina> thanx
[3/10/2005 9:12 AM] <dasarath> semantic differences: the way the next method is
implemented is different
[3/10/2005 9:12 AM] <sanjiva> Dasarath: can you explain it here or post a
detailed note to the list explaining the problem with databinding? Actually the
latter is necessary even if you explain it here :-)
[3/10/2005 9:13 AM] <dasarath> we (ajith and my self) are trying to get the OM
interfaces lined up with xmlbeans
[3/10/2005 9:13 AM] <alek_s> next method should be implemented following StAX
spec
[3/10/2005 9:13 AM] <dasarath> this is the problem
[3/10/2005 9:15 AM] <dasarath> in OM when an XMLStreamReader is passed it
begins building by calling next
[3/10/2005 9:16 AM] <dasarath> but the XMLStreamReader obtained from xmlbeans
is already positioned on the first element
[3/10/2005 9:17 AM] <dasarath> so when OM calls next on it, the first element
is missed
[3/10/2005 9:17 AM] <alek_s> so just check if current event is START ELEMENT
and if nto call next?
[3/10/2005 9:17 AM] -->| Chamil ([EMAIL PROTECTED]) has joined #apache-axis
[3/10/2005 9:17 AM] <dasarath> alek_s: that's the same thing that we are doing
but this change
[3/10/2005 9:18 AM] <dasarath> affects a whole lot of other code in OM
[3/10/2005 9:18 AM] <dasarath> and causes OM to fail at lot of other places
[3/10/2005 9:18 AM] <dasarath> there were some issues with the M1 doc/lit impl
as well
[3/10/2005 9:19 AM] <alek_s> well this has ntohing reallly to do with StAX
"semantics" ...
[3/10/2005 9:19 AM] <alek_s> semantcis are well defined what parser returns
when next is called - it is only when you use it in XML builder
[3/10/2005 9:19 AM] <dasarath> its an integration problem
[3/10/2005 9:20 AM] <alek_s> you made aditional assumptions
[3/10/2005 9:20 AM] <dasarath> :)
[3/10/2005 9:23 AM] <dasarath> shall we discuss MTOM impl
[3/10/2005 9:23 AM] <thilina> k
[3/10/2005 9:24 AM] <thilina> anybody had any time to look in to the impl ?? :)
[3/10/2005 9:25 AM] <dasarath> sure go ahead:)
[3/10/2005 9:25 AM] <thilina> at the moment it supports only MTOM messages
[3/10/2005 9:25 AM] <Deepal> u mean ?
[3/10/2005 9:25 AM] <dasarath> u mean?
[3/10/2005 9:25 AM] <dasarath> mime messages.?
[3/10/2005 9:25 AM] <thilina> v r expecting the transport to distinguish
between whether the incvoming is mtom or pure soap
[3/10/2005 9:26 AM] <Deepal> oh ok
[3/10/2005 9:26 AM] <thilina> Dasarath : MTOM optimised mime messages
[3/10/2005 9:26 AM] <dasarath> thilina: shall we call them mime/vs. non-mime
[3/10/2005 9:27 AM] <alek_s> how do you know from transport that it is
optimized? content-type MIME multi-part?
[3/10/2005 9:27 AM] <dasarath> alek: http headers
[3/10/2005 9:27 AM] <alek_s> content-type?
[3/10/2005 9:27 AM] <thilina> mtom spec defines a binding
[3/10/2005 9:27 AM] <sanjiva> yeah the http content type is multi-part for
optimize stuff right?
[3/10/2005 9:27 AM] <thilina> yep
[3/10/2005 9:27 AM] <Chinthaka_> know "optimized" from headerd ?
[3/10/2005 9:27 AM] <Deepal> alek : yep
[3/10/2005 9:28 AM] <Chinthaka_> headers ?
[3/10/2005 9:28 AM] <thilina> yes from the content type header filed
[3/10/2005 9:28 AM] <Chinthaka_> I don't think
[3/10/2005 9:28 AM] <Chinthaka_> you can guess that it has MTOM stuff
[3/10/2005 9:28 AM] <thilina> :)
[3/10/2005 9:28 AM] <Chinthaka_> but can not guess whether optimized or not
[3/10/2005 9:29 AM] <Chinthaka_> for example, that MIME can only contain base64
encoded stuff
[3/10/2005 9:29 AM] <thilina> assumed dat mime stuff always come as MTOM
[3/10/2005 9:29 AM] <Chinthaka_> but not MTOM optimized
[3/10/2005 9:30 AM] <Deepal> yep : but i think both have to treat as same way
[3/10/2005 9:30 AM] <thilina> but then it should adhere to some spec
[3/10/2005 9:30 AM] <alek_s> is there soem way to know that message is MTOM and
not WS-Attachment?
[3/10/2005 9:30 AM] <Deepal> if it is a MIME message
[3/10/2005 9:30 AM] <Chinthaka_> Alek, I also have the same prob :(
[3/10/2005 9:30 AM] <thilina> me too:(
[3/10/2005 9:30 AM] <dasarath> thilina: can u summerize ur design
[3/10/2005 9:31 AM] <Chinthaka_> if this is irrespective of the transport,
thats great
[3/10/2005 9:31 AM] <thilina> but HOW?
[3/10/2005 9:32 AM] <alek_s> it seesm that subtype code in Content-type may be
used
[3/10/2005 9:32 AM] <thilina> anybody has any clues?
[3/10/2005 9:32 AM] <alek_s> liek in this example: Content-Type:
Multipart/Related;boundary=MIME_boundary;
[3/10/2005 9:32 AM] -->| Ajith ([EMAIL PROTECTED]) has joined #apache-axis
[3/10/2005 9:32 AM] <alek_s> type="application/xop+xml";
[3/10/2005 9:32 AM] <alek_s> see:
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/com.sap.km.cm.docs/documents/a1-8-4/Evolution%20of%20Web%20Services%20Attachments%20Technologies.article
[3/10/2005 9:32 AM] <Ajith> sorry guys
[3/10/2005 9:32 AM] <Ajith> git stuck in the traffic
[3/10/2005 9:33 AM] <dasarath> isn't this a problem to be sorted out in the
transport?
[3/10/2005 9:33 AM] <thilina> i think so
[3/10/2005 9:33 AM] <dasarath> I mean identify what builder to use?
[3/10/2005 9:34 AM] <dasarath> whether the message is SwA, MTOM or neither SwA
or MTOM
[3/10/2005 9:35 AM] <thilina> currently its happening like this
[3/10/2005 9:35 AM] <thilina> transport decides wat builder to use
[3/10/2005 9:36 AM] <thilina> depending on weather it is MTOM opmised or non
mtom
[3/10/2005 9:36 AM] <alek_s> i would keep this is in transport as higher layers
should nto care and work only with Infoset (as much as possible)
[3/10/2005 9:36 AM] <thilina> tehn builde will be given a input stream
[3/10/2005 9:37 AM] <Chinthaka_> well in current Axis 2 also the builder will
be created in the transoprt, so this will fit in well
[3/10/2005 9:37 AM] <thilina> it'll apss it ot a mime parser and obtain root
part
[3/10/2005 9:38 AM] <dasarath> thilina how do u differentiate b/w normal text
and base64 encoded text at the receiver?
[3/10/2005 9:38 AM] <thilina> which will contain the soap meesage
[3/10/2005 9:38 AM] <Chinthaka_> Thilina, small question. Say,
[3/10/2005 9:38 AM] <Chinthaka_> ohh, Dasarath, u asked the question :)
[3/10/2005 9:38 AM] <thilina> it's problem
[3/10/2005 9:38 AM] <dasarath> :)
[3/10/2005 9:39 AM] <thilina> it seems we can diff between them only after
lokiing at the wasdl
[3/10/2005 9:39 AM] <thilina> wsdl
[3/10/2005 9:39 AM] <dasarath> i would like to see the same OM tree built at
the receiver as well
[3/10/2005 9:39 AM] <Chinthaka_> WSDL says its base64, but how do we know its
MTOM base64 or normal base64 ?
[3/10/2005 9:39 AM] <thilina> cannot think about a way to differentiate when
parsing the message
[3/10/2005 9:40 AM] <Chinthaka_> I mean to include that in Blob or not ?
[3/10/2005 9:40 AM] <thilina> Eran: dat doesn't mattter a lot
[3/10/2005 9:40 AM] <dasarath> but we do not do schema aware passing at the
moment...
[3/10/2005 9:40 AM] <thilina> i'm taliking about de-serializer
[3/10/2005 9:41 AM] <thilina> so i think it's better to put dat in a OMText
[3/10/2005 9:41 AM] <Chinthaka_> schema aware parsing for OM ......... :( :(
[3/10/2005 9:41 AM] <dasarath> alek: is ur MTOM toy in the svn?
[3/10/2005 9:41 AM] <thilina> i mean non- optimised base 64 binary parts
[3/10/2005 9:41 AM] <Chinthaka_> Thilina : +1
[3/10/2005 9:42 AM] <Ajith> guys sorry about poking in but is this about
creating something specific to base64bin at the parser level ?
[3/10/2005 9:42 AM] <dasarath> ajith can u illaborate pls
[3/10/2005 9:43 AM] <Chinthaka_> yes, Ajith
[3/10/2005 9:43 AM] <thilina> Then we can have a getDataHandler methode in the
[3/10/2005 9:43 AM] <thilina> OMText also :)
[3/10/2005 9:43 AM] <Chinthaka_> but Thilina agreed to create OMText out of
base64 ;)
[3/10/2005 9:43 AM] <alek_s> Chinthaka: i never finished my MTOM impl
[3/10/2005 9:44 AM] <Ajith> well I was thinking about such a thing and came up
with a cool concept
[3/10/2005 9:44 AM] <dasarath> alek: <dasarath> alek: is ur MTOM toy in the svn?
[3/10/2005 9:44 AM] <dasarath> :)
[3/10/2005 9:44 AM] <Ajith> I call it "builder extensions"
[3/10/2005 9:44 AM] <thilina> go ahead
[3/10/2005 9:45 AM] <alek_s> the way i was thinking was that after parsing you
have <xop:include ..> elements that are resolved on demand when app actually
needs them
[3/10/2005 9:45 AM] <Chinthaka_> Dasarath, come one, u got the answer any way :D
[3/10/2005 9:45 AM] <Chinthaka_> Alek : there might not be xop:include always
[3/10/2005 9:45 AM] <thilina> it's wat we r doing at the moment :)
[3/10/2005 9:46 AM] <thilina> alek
[3/10/2005 9:46 AM] <alek_s> and you have special api to access binary data -
if you do not use this API then you get BASE64 and you do not knwo if it is
MTOM or just BASE64
[3/10/2005 9:46 AM] <Ajith> when you want schema aware parsing (building) you
can generate a builder extension and put it in the service.xml (server.xml) so
that the builder will use it in creating the OM tree
[3/10/2005 9:46 AM] -->| sanjiva_ ([EMAIL PROTECTED]) has joined #apache-axis
[3/10/2005 9:46 AM] |<-- sanjiva has left irc.freenode.org (Read error: 131
(Connection reset by peer))
[3/10/2005 9:47 AM] <dasarath> correct me if I'm wrong but
[3/10/2005 9:47 AM] <Ajith> I was thinking of this kind of thing for the SOAP
builder
[3/10/2005 9:47 AM] <dasarath> if I construct an OMBlob and use it to send
non-optimized bin content
[3/10/2005 9:47 AM] <dasarath> on the other side I will have OM text in place
of OMBlob
[3/10/2005 9:48 AM] <Chinthaka_> Alek, didn't get what u said :(
[3/10/2005 9:48 AM] <Ajith> In my way you have a parser that is aware of that
[3/10/2005 9:48 AM] <Ajith> so that binary content will always be binary content
[3/10/2005 9:48 AM] <thilina> in the current api OMBlob & OMText has methods
called getDataHandler
[3/10/2005 9:49 AM] <Ajith> hmmmmm
[3/10/2005 9:49 AM] <alek_s> there are no xop:include then it is not MTOM/XOP?!
[3/10/2005 9:49 AM] <Ajith> what does the OMtext.getDatahandler return ?
[3/10/2005 9:49 AM] <thilina> MTOM optimised data came in mime parts
+<xop:include> will be handled by blob
[3/10/2005 9:49 AM] <thilina> OMBLob
[3/10/2005 9:50 AM] <alek_s> you need to process Original Infoset (wit binary)
into XOP infoset with xop:Include
[3/10/2005 9:50 AM] <thilina> non optimised data came as base64 among other
elements will be handled by OMTExt
[3/10/2005 9:51 AM] <thilina> yeah
[3/10/2005 9:51 AM] <alek_s> looks good to me - so what is the problem with
this?
[3/10/2005 9:51 AM] <Chinthaka_> Alek, what if its not optmized, then
xop:include is not there ?
[3/10/2005 9:51 AM] <thilina> yeah
[3/10/2005 9:51 AM] <thilina> chithaka: yep
[3/10/2005 9:52 AM] <dasarath> so we cannot differentiate b/w b64 bin and
normal text
[3/10/2005 9:52 AM] <thilina> dasrath : untill we hav wsdl
[3/10/2005 9:52 AM] <Ajith> schema aware parsing guys :)
[3/10/2005 9:52 AM] <Ajith> thats the solution :)
[3/10/2005 9:52 AM] <dasarath> well I'm not sure that is the way to go
[3/10/2005 9:53 AM] <thilina> dasrath : to whome
[3/10/2005 9:53 AM] <dasarath> that is going to be very heavy work
[3/10/2005 9:53 AM] <Chinthaka_> thats too much , IMHO
[3/10/2005 9:53 AM] <dasarath> ajith did u fix the OM
[3/10/2005 9:53 AM] <Chinthaka_> anyway ALek, shall we understad this well
[3/10/2005 9:53 AM] <thilina> at the moment OMBlob returns only a SData Handler
[3/10/2005 9:54 AM] <Chinthaka_> you can have either optimized data,
non-optimized base64, just base64 test, just text
[3/10/2005 9:54 AM] <Chinthaka_> we can identify optimized stuff by xop:include
[3/10/2005 9:54 AM] <Chinthaka_> but how abt others ?
[3/10/2005 9:54 AM] <thilina> the user has to come up with dataSources+....
stuff related to the data type they are using to get object s out of it
[3/10/2005 9:55 AM] <alek_s> well you do not need to do that much of
identification
[3/10/2005 9:55 AM] <dasarath> alek: like what? e.g.
[3/10/2005 9:55 AM] <alek_s> if message is not inside multi-part mime it can
not be MTOM/XOP optimized right ?
[3/10/2005 9:55 AM] <Chinthaka_> ok
[3/10/2005 9:55 AM] <alek_s> only if transport has message as multi-part
[3/10/2005 9:56 AM] <thilina> yeah
[3/10/2005 9:56 AM] <dasarath> sure but MTOM allows for non-optimized binary
right?
[3/10/2005 9:56 AM] <thilina> they will be coming ass base64
[3/10/2005 9:56 AM] <alek_s> and type is "application/xop+xml";
[3/10/2005 9:56 AM] <alek_s> then you know it is XOP optimzied
[3/10/2005 9:56 AM] <Chinthaka_> Thilina : ;)
[3/10/2005 9:56 AM] <alek_s> so builder needs to follow two stage infoset
creation
[3/10/2005 9:56 AM] <alek_s> first: XOP Infoset (with unresolved xop:Include)
[3/10/2005 9:57 AM] <thilina> ???
[3/10/2005 9:57 AM] <alek_s> then second stage reconstructing Original Infoset
[3/10/2005 9:57 AM] <dasarath> I don't think we are doing two stage inforset
creation
[3/10/2005 9:57 AM] <alek_s> first stage means simpel XML parsing and minimum
modifications (like OMBlob)
[3/10/2005 9:57 AM] <dasarath> alek: are u proposing that we expose expose
xop:include in OM
[3/10/2005 9:57 AM] <dasarath> ?
[3/10/2005 9:58 AM] <thilina> like OMBlob ???
[3/10/2005 9:58 AM] <Chinthaka_> alek, u mean identifying xop:includes only ?
[3/10/2005 9:58 AM] <alek_s> second stage is to show Original Infoset and will
require replacing xop:include/OMBlolb with BASE64 for non-MTOM enabled API
[3/10/2005 9:58 AM] <Chinthaka_> Dasarath, that can be done
[3/10/2005 9:58 AM] <Chinthaka_> I've done similar thing for SOAP
[3/10/2005 9:58 AM] <alek_s> no i do not propose that
[3/10/2005 9:58 AM] <dasarath> sure that can be done but the problem is we are
not exposing the mime parser
[3/10/2005 9:58 AM] <alek_s> i just describe how MTOM/XOP mapping happens
[3/10/2005 9:58 AM] <thilina> alek: wat u say is not to hav a binary node in
the OM
[3/10/2005 9:58 AM] <alek_s> developer access only second stage: Original
Infoset
[3/10/2005 9:58 AM] <thilina> after second stage
[3/10/2005 9:59 AM] <thilina> am I correct
[3/10/2005 9:59 AM] <alek_s> it has already BASE64 (or binary if MTOM-optimized
OM API is used when you create such API ...)
[3/10/2005 9:59 AM] <alek_s> in XML Infoset there is not binary
[3/10/2005 9:59 AM] <alek_s> only BASE64 and you can not say if it is "binary"
or just "texT"
[3/10/2005 10:00 AM] <alek_s> you need soem special API that access
optimized-MTOM to know that this particular BASE64 content is really binary
[3/10/2005 10:00 AM] <alek_s> and you do not read it as text but use
InputStrea, ContentDataHandler or whatever
[3/10/2005 10:00 AM] <alek_s> it is especially important for very large
attachments
[3/10/2005 10:00 AM] <dasarath> alek: in thilina's impl this is what we have
[3/10/2005 10:00 AM] <alek_s> like >1GB (size of typical JAva heap)
[3/10/2005 10:01 AM] <dasarath> thilina pls correct if I'm wrong
[3/10/2005 10:01 AM] <Chinthaka_> Alek, 'm bit confused. Can u later please
sent a mail with an example xml
[3/10/2005 10:01 AM] <alek_s> convertign soemthing like that to BASE64 and
returning as String may get OutOfMemoryException in JVM
[3/10/2005 10:01 AM] <dasarath> there is a OMBlob
[3/10/2005 10:01 AM] <alek_s> exmaple of what?
[3/10/2005 10:02 AM] <Chinthaka_> the method u talked about idetifying MTOM
stuff
[3/10/2005 10:02 AM] <dasarath> OK another problem
[3/10/2005 10:02 AM] <dasarath> what if we need to pass bin to xmlbeans?
[3/10/2005 10:03 AM] <Chinthaka_> the URL u gave earlier has something like
that, Alek, please if you have time please put that email
[3/10/2005 10:03 AM] <alek_s> it is in XOP and MTOM specs
[3/10/2005 10:03 AM] <dasarath> then I see no option but to convert the whole
string to base64
[3/10/2005 10:03 AM] <Chinthaka_> Dasarath : Good question :|
[3/10/2005 10:03 AM] <dasarath> i would say that very awkward
[3/10/2005 10:04 AM] <alek_s> xmlbeans is nto designed to handle binary
attachments
[3/10/2005 10:04 AM] <thilina> alek: i'm not sure abut that
[3/10/2005 10:04 AM] <dasarath> :)
[3/10/2005 10:04 AM] <dasarath> so our MTOM is useless when data binding is
there...?
[3/10/2005 10:04 AM] <thilina> i'm talking about xop & mto spec thng
[3/10/2005 10:04 AM] <alek_s> it will run out of memory - xmlbeans is exactly
liek DOM and may be even more memory intensive
[3/10/2005 10:04 AM] <alek_s> what do you want to do with xmlbeans and MTOM?
[3/10/2005 10:05 AM] <Chinthaka_> so MTOM is out with XML beans as a data
binding tool ?
[3/10/2005 10:05 AM] <alek_s> no, just it cannto handle very large binary
attachments
[3/10/2005 10:05 AM] -->| chathura ([EMAIL PROTECTED]) has joined #apache-axis
[3/10/2005 10:05 AM] <dasarath> think of the purchase order XML
[3/10/2005 10:05 AM] <dasarath> what is there was binary content in that schema
[3/10/2005 10:05 AM] <alek_s> very large means more than 100s MBs
[3/10/2005 10:05 AM] <alek_s> if it is just few MBs it is just fine
[3/10/2005 10:06 AM] <dasarath> we could use our MTOM impl to send it optimized
[3/10/2005 10:06 AM] <thilina> v didn't resolv the identfiyng problem yet
[3/10/2005 10:06 AM] <alek_s> (all of course will be validated when you try to
do it and test it)
[3/10/2005 10:06 AM] <dasarath> but the receiver needs to convert it to base64
to feed xmlbeans
[3/10/2005 10:06 AM] <alek_s> the problem is not with sending but what to keep
in memory
[3/10/2005 10:06 AM] <thilina> i mean how diff btween ws-attachment & mtom in
transport layer
[3/10/2005 10:06 AM] <alek_s> for vary large attachment bianry data should
never be kept in memory but streamed in/out of file or database (or other
storage)
[3/10/2005 10:07 AM] <alek_s> it should be simpel enought to give users an
option and if message has attachments bigger than K MBs just throw exception
saying it is not supported
[3/10/2005 10:08 AM] <alek_s> if they do not set this option they may get OME
[3/10/2005 10:08 AM] <alek_s> and for those that want to handle very large
binary data they need to use other binding (or no binding and work directly
with MTOM/AXIOM)
[3/10/2005 10:10 AM] <dasarath> u mean don't use data binding when very large
binary data is involved
[3/10/2005 10:10 AM] <dasarath> ?
[3/10/2005 10:11 AM] <dasarath> and use the AXIOM MTOM impl directly
[3/10/2005 10:11 AM] <alek_s> in nutshell: yes
[3/10/2005 10:11 AM] <dasarath> :)
[3/10/2005 10:12 AM] <alek_s> and allow multiple bindings
[3/10/2005 10:13 AM] <alek_s> so somebody can construct "custom" binding to
what they want with XML the way they want
[3/10/2005 10:13 AM] <thilina> is there any restrictions that AXIOM should
adhere to xml infoset
[3/10/2005 10:13 AM] <thilina> we can make it XOP infoset
[3/10/2005 10:14 AM] <thilina> so that OMBlob with binary can be used
[3/10/2005 10:14 AM] <thilina> & it'll be serialised as <xop:include>
[3/10/2005 10:14 AM] <dasarath> what is the first even that OM should throw
when someone calls next on XMLStreamReader obained from OMElement.getPullParser
[3/10/2005 10:14 AM] <dasarath> even=event
[3/10/2005 10:15 AM] <dasarath> xmlbeans moves to the first child...
[3/10/2005 10:15 AM] <dasarath> OM behaves like java iterator...
[3/10/2005 10:16 AM] <dasarath> u must call next before u can call getName or
any of the accessor methods
[3/10/2005 10:16 AM] <thilina> in the case that MOBlob is not qualified to
optimise using MTOM v can create an OMText insted of OMbBlob & it'll be
serialised as base 64
[3/10/2005 10:16 AM] <dasarath> further
[3/10/2005 10:16 AM] <alek_s> StAX is always positioned on event - so it is not
like Java iterator
[3/10/2005 10:16 AM] <dasarath> so we need to change OM then
[3/10/2005 10:16 AM] <dasarath> another point
[3/10/2005 10:17 AM] <dasarath> In the StAX reference impl
[3/10/2005 10:17 AM] <dasarath> if u have an xml like
[3/10/2005 10:17 AM] <dasarath> <foo xmlns="http://foo.com";>
[3/10/2005 10:17 AM] <dasarath> calling getNamespaceCount returns 0
[3/10/2005 10:17 AM] <dasarath> is this correct?
[3/10/2005 10:18 AM] <dasarath> the spec doesn't say anything about this
[3/10/2005 10:18 AM] <Chinthaka_> I did a hack to handle this in OM builder :(
[3/10/2005 10:18 AM] <dasarath> I would like to clarify this...
[3/10/2005 10:19 AM] <alek_s> i do not remeber - it may be that default
namespace is not counted
[3/10/2005 10:19 AM] <Chinthaka_> Alek, yes
[3/10/2005 10:20 AM] <alek_s> but you can still check what is current defautl
namespace
[3/10/2005 10:20 AM] <alek_s> (AFAIR)
[3/10/2005 10:21 AM] <dasarath> yes but the current OM fails when this happens
[3/10/2005 10:21 AM] <dasarath> :)
[3/10/2005 10:21 AM] <dasarath> thilina:
[3/10/2005 10:21 AM] <thilina> yes
[3/10/2005 10:21 AM] <Chinthaka_> Dasarath, it was fixed
[3/10/2005 10:22 AM] <dasarath> u do not process <xop:include> any differently
when u use XMLStreamReader
[3/10/2005 10:22 AM] <dasarath> ERAN: thx
[3/10/2005 10:22 AM] <dasarath> :)
[3/10/2005 10:23 AM] <dasarath> infact parser need not now that xop:include
element has special meaning
[3/10/2005 10:23 AM] <thilina> yeah. now wat i'm doing is when
theXMLStreamReader passes a Element I cahck whethet it is <XOp:include>
[3/10/2005 10:23 AM] <thilina> yeah
[3/10/2005 10:23 AM] <alek_s> keep in mind difference between XOP Infoset (that
is resutl of MTOM) and "Original" Infoset
[3/10/2005 10:23 AM] <thilina> but i 'm thinking of coming up with something
like MTOMXMLStreamREader which will understand
[3/10/2005 10:24 AM] <alek_s> if you see xop:Include you deal with XOP Infoset
[3/10/2005 10:24 AM] <alek_s> it is not XML Infoset ...
[3/10/2005 10:24 AM] <dasarath> exactly
[3/10/2005 10:25 AM] <dasarath> how about renaming getPullParser in OMElement
as newXMLStreamReader
[3/10/2005 10:25 AM] <alek_s> you need layer (API or whatever) on top of XOP
Infoset to make it present what was in "Original" Infoset (before MTOM
optimized it)
[3/10/2005 10:26 AM] <dasarath> alek: what is the nature of that API? Streaming
or DOM like?
[3/10/2005 10:27 AM] <--| Deepal has left #apache-axis
[3/10/2005 10:27 AM] <Chinthaka_> :)
[3/10/2005 10:29 AM] <Chinthaka_> is that all for the day ?
[3/10/2005 10:29 AM] <alek_s> i think so
[3/10/2005 10:30 AM] <dasarath> k
[3/10/2005 10:30 AM] <alek_s> can soembody post irc chat log to mailing list
and wiki?
[3/10/2005 10:30 AM] <Chinthaka_> bye all
[3/10/2005 10:30 AM] <Chinthaka_> I will do that this time
[3/10/2005 10:30 AM] <--| dasarath has left #apache-axis
[3/10/2005 10:31 AM] <alek_s> k
[3/10/2005 10:31 AM] <alek_s> bye all
}}}
