Main topics of the day was MTOM and data binding ...
[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