pull processing patterns / XML Schema [Re: 1.5 Release

[Aleksander Slominski <as...@cs.indiana.edu>]

Samisa Abeysinghe wrote:

>Dims,
>      I had a look into how the problem could be fixed for Goole API.
>As we discussed in the other thread, this is a problem with the
>"assumtion" on the XML element ordering. Now to fix this, we have to
>fix SoapDeSerializer class (earlier I thought it is the parser, but it
>happens to be SoapSeSerializer). We have to buffer the AnyElement
>returned by the parser at the SoapDeSerializer level if the
>m_pchNameOrValue not what is requested by the generated code and go on
>looking for next nodes. This obviously is a major change, looking at
>the number of methids using the parser next() methid in
>SoapDeSerializer. And ofcource, I *think* this would work, but we have
>to verify. It will take couple of days to update the code. However it
>will take much more time to test and fix for side effects.
>  
>
you need to have to use different patterns of pull parsing:

if you need to process xs:all you already know names of all elements so 
yo do not need to buffer
- you can deserialize as you go and do checks as you go [if(already 
processed child)]

http://www.extreme.indiana.edu/~aslom/xmlpull/patterns.html#ANY_ORDER

at the end of processing xs:all do a quick check that all required 
elements were present (and other occurrence requirements):

otherwise the simplest processing is for homogeneous xs:sequence such as 
arrays - that is what i think you are doing already for arrays:

http://www.extreme.indiana.edu/~aslom/xmlpull/patterns.html#SEQUENCE

and this is what i think is happening inside stubs - they mirror 
expected XML structure:

http://www.extreme.indiana.edu/~aslom/xmlpull/patterns.html#MIRROR

with possibly open xsd:any model in some places that can be deserialized 
into XML Infoset Element or skipped:

http://www.extreme.indiana.edu/~aslom/xmlpull/patterns.html#SKIP


HTH,

alek

>     May be we could have looked into public APIs like these earlier.
>However, if we are to fix this and release, it will take another month
>or so for the code to stabilize. And those who want to use 1.5 for
>client engagements, would not like idea of changing a sensitive class
>as SoapDeSerializer at this moment.
>     What if we do release 1.5 as it is and include this to 1.6?
>Thanks,
>Samisa...
>
>On Tue, 22 Mar 2005 15:33:01 -0500, Davanum Srinivas <da...@gmail.com> wrote:
>  
>
>>John,
>>
>>I have been playing with the code...I was thinking what is the use of
>>making a release if people can't use it to access public web services
>>like Amazon, Google, TerraService and eBay? Can we spend some time to
>>make our code robust and useful in the real world out-of-the-box? (I
>>can definitely confirm that the code genned out of the box does not
>>work with Google Search API for starters)
>>
>>Thanks,
>>dims
>>
>>On Tue, 22 Mar 2005 18:29:04 +0000, John Hawkins <ha...@uk.ibm.com> wrote:
>>    
>>
>>>I think we should go for a 1.5 release which is client biased next wk.
>>>
>>>The server will still work but may have issues.
>>>
>>>Thoughts?
>>>
>>>
>>>
>>>
>>> "Carsten Blecken" <cb...@macrovision.com>
>>>
>>>22/03/2005 18:15
>>>
>>>Please respond to
>>> "Apache AXIS C Developers List"
>>>
>>>
>>>To "Apache AXIS C Developers List" <ax...@ws.apache.org>
>>>
>>>cc
>>>
>>>Subject RE: 1.5 Release
>>>
>>>
>>>
>>>
>>>
>>>Hi,
>>>
>>> sorry for the late reply. Maybe a beta could help to get the
>>> client side improvements out. Certainly worth considering,
>>> IMO.
>>>
>>> It is not that the server side is not important, but I do have
>>> some concerns about the current server side approach (There is an
>>> interesting writeup on
>>> http://fremantle.org/paul/Web_Services_Server_options_for_Axis_C.html)
>>> and we might need to address the server side in a separate
>>> release.
>>>
>>> Carsten
>>>
>>>
>>> -----Original Message-----
>>> From: Samisa Abeysinghe [mailto:sabeysinghe@virtusa.com]
>>> Sent: Friday, March 18, 2005 10:14 AM
>>> To: Apache AXIS C Developers List
>>> Subject: Re: 1.5 Release
>>>
>>>
>>> Hi Sanjaya,
>>>                 We have not attended server side as such. However, many
>>>fixes to
>>> serialization/de-serialization in general and code generation has solved
>>> many problem which were generic to both sides.
>>>
>>>                 We have done some level of testing with C++ server against
>>>C++ clients
>>> and about 65% of the tests pass. Some of the failing ones are due to
>>> Skeleton implementation errors. So I would rather say that the code base
>>> is fairly stable.
>>>                 I have been able to fix the simple axis server issue as
>>>well. Hence my
>>> feeling is that this is above beta quality (compared to 1.4 etc) and we
>>> could do a 1.5 final.
>>>
>>> Thanks,
>>> Samisa...
>>>
>>> On Thu, 2005-03-17 at 10:27, sanjaya singharage wrote:
>>> > Hi all,
>>> >
>>> > Are we attending to the serverside issues?
>>> >
>>> > How about releasing a beta? but making sure that the client side is
>>> > release quality. That way the beta will offer a snap shot of the
>>> > stable client side for people who want the client features quickly and
>>> > it will not be the final.(However originally in the release plan a
>>> > beta was not talked about). But this does present a problem for us
>>> > over here because we will only be able to test against the Axis c++
>>> > server side.But we need to have the serverside operate reasonably even
>>> > for a beta.
>>> >
>>> > I need some time to integrate the services to the ant services
>>> > framework (should be able to do it by tomorrow).and then we can see
>>> > how the serverside is operating.
>>> >
>>> > what do you think folks? any other options available? Is it possible
>>> > to go for a code freeze?
>>> >
>>> > sanjaya.
>>> --
>>> Samisa Abeysinghe <sa...@virtusa.com>
>>> Virtusa Corporation
>>>
>>>
>>>      
>>>
>>--
>>Davanum Srinivas - http://webservices.apache.org/~dims/
>>
>>    
>>


-- 
The best way to predict the future is to invent it - Alan Kay