prototype of lightweight XML infoset API [Re: WSA / Infoset / oither observations [Re: WS-Addressing Implementation]]

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

Davanum Srinivas wrote:

>+1 from me....Where do we start? ("lightweight XML infoset API")
>  
>
i have a prototype implemented.

all is based around java interfaces to allow easy layering it upon *any* 
XML document model and interfaces are direct one-to-one translation of 
XML Infoset information items with properties mapped to get/set methods 
plus some set of utility methods mostly to expose some minimal XPath 
like operation (for full blown XPath processing i have Jaxen Navigator 
Plugin for it).

so it is very usable but still a long way before it is a stable set of 
interfaces so i would love to have it reviewed / hear some comments :-)

BTW: my current plan is to make it use JDK 1.5 as soon as it becomes 
non-beta so processing XML is feeling right by using foreach(), 
generics, etc. for example wouldnt it be nice to be able to write:

        for(XmlElement policy :  ep.getPolicy()) {
            
System.out.println("policy["+(++pos)+"]="+builder.serializeToString(policy));
        }

instead of

        for(Iterator i = ep.getPolicy().iterator(); i.hasNext(); ++pos) {
            XmlElement policy = (XmlElement) i.next();
            
System.out.println("policy["+pos+"]="+builder.serializeToString(policy));
        }

current code is here:
http://www.extreme.indiana.edu/viewcvs/~checkout~/XPP3/java/src/java/builder/org/xmlpull/v1/builder/

thanks,

alek

>-- dims
>
>--- Aleksander Slominski <as...@cs.indiana.edu> wrote:
>  
>
>>Davanum Srinivas wrote:
>>
>>    
>>
>>>All valid points. i was trying to use DOM to be able to support other toolkits. 
>>>
>>> 
>>>
>>>      
>>>
>>hi,
>>
>>based on my experience it seems that it is feasible to have a 
>>lightweight XML infoset API that could be used directly to create a 
>>_very_ lightweight way to incrementally build XML trees. this makes it 
>>very natural to translate one of WS specs that uses XML Infoset into 
>>Java code ...
>>
>>XML Infoset API can be very handy  if you allow tree to contain not only 
>>Information Items but also *any* Java objects: you then can build XML 
>>tree to represent XML message with Java objects that are not yet 
>>serialized to XML (SOAP Headers and Body content) that is then refined 
>>by pipeline into XML Infoset either in pipeline or just before sending. 
>>similarly receiving can work by replacing parts of XL Infoset (such as 
>>SOAP Header representing WSSE) into Java objects. i think it i very 
>>elegant and powerful approach.
>>
>>still the difficulty lies in situation when you need to pass XML Infoset 
>>to library that requires DOM2/3/4. i think it is feasible to create DOM 
>>API implementation on top of Infoset API however it is not easy - that 
>>would make doing such things like XML signatures with xmlsec maybe 
>>faster but AFAIK it is not possible to do real streaming message signing 
>>as SOAP does not have concept of footers so you need to keep whole XML 
>>message in memory to be able to add SOAP header with security before 
>>sending ...
>>
>>i think it strikes right balance between DOM and using raw objects (as 
>>described by Glen) as it put everything in context of XML Infoset.
>>
>>i am curious what other people think about those topics.
>>
>>thanks.
>>
>>alek
>>
>>    
>>
>>>--- Glen Daniels <gd...@sonicsoftware.com> wrote:
>>> 
>>>
>>>      
>>>
>>>>Hi dims:
>>>>
>>>>I took a look at this, and I guess I have some of the same questions I did
>>>>about the WS-Security stuff.  Using DOM for everything will make this less
>>>>efficient.  Since we use the SerializationContext to write all our XML,
>>>>converting objects like these to DOM first involves a) extra memory, b)
>>>>extra time writing from Java->DOM and then from DOM->SerializationContext
>>>>API calls.  Mightn't this be better either built with the objects
>>>>serializing themselves using the SerializationContext directly (as in
>>>>MessageElement.outputImpl()) or with raw data objects using a separate
>>>>serializer to walk the tree and write the XML?
>>>>
>>>>Clearly there's lots more to do here in terms of hooking this up to
>>>>generating endpoint references from our service descriptions, using the
>>>>headers to actually route messages, etc. but this was my initial impression.
>>>>
>>>>   
>>>>
>>>>        
>>>>
>>><SNIP/>
>>> 
>>>
>>>      
>>>
>>>>--Glen
>>>>
>>>>----- Original Message ----- 
>>>>From: "Davanum Srinivas" <di...@yahoo.com>
>>>>To: <pm...@ws.apache.org>; <ge...@ws.apache.org>
>>>>Sent: Wednesday, February 11, 2004 11:44 AM
>>>>Subject: WS-Addressing Implementation
>>>>
>>>>
>>>>   
>>>>
>>>>        
>>>>
>>>>>FYI, http://ws.apache.org/ws-fx/addressing/
>>>>>
>>>>>-- dims
>>>>>
>>>>>=====
>>>>>Davanum Srinivas - http://webservices.apache.org/~dims/
>>>>>
>>>>>---------------------------------------------------------------------
>>>>>To unsubscribe, e-mail: pmc-unsubscribe@ws.apache.org
>>>>>For additional commands, e-mail: pmc-help@ws.apache.org
>>>>>
>>>>>
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>=====
>>>Davanum Srinivas - http://webservices.apache.org/~dims/
>>> 
>>>
>>>      
>>>
>>-- 
>>The best way to predict the future is to invent it - Alan Kay
>>
>>
>>    
>>
>
>
>=====
>Davanum Srinivas - http://webservices.apache.org/~dims/
>  
>


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