[Apache Web Services Wiki] New: ChatAgenda/20050310/ChatLog

[ge...@ws.apache.org]

   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 (~Miranda@220.247.221.242) 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 (~Chamil@220.247.245.210) 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 (~Miranda@220.247.245.210) 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_ (~sanjiva@203.94.84.117) 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 (~chathura@220.247.221.242) 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
}}}