Re: Continued development of XMLPull

 > Alek wrote:
> 
> i see no problem in using XPP3 (or XPP4) as a vehicle to test such 
> ideas. i am also toying with an idea if taking back modifications to 
> XPP3 that happened in StAX RI (it is based on XPP3) and merge them back 
> to XPP4 codebase so it would implement both XmlPull and StAX ...


I think using XPP (and kXML) as test vehicle for new features is a very 
good idea. Supporting both interfaces is probably the best option for 
XPP, but may not be ideal for kXML. The problem I see with improving the 
xmlpull interface significantly is that xmlpull basically is a common 
interface for XPP and kXML, but what's good for XPP is often not ideal 
for kXML.

Moreover, in the mobile area, SAX was introduced with JSR 172, and if I 
want to use a pull parser somewhere instead, that is simpler to justify 
if I do not need to explain the difference between XmlPull and StAX. 
StAX also may help to counter arguments like "but SAX is the standard" 
better than xmlpull.

Perhaps we should simply shift the xmlpull web site focus a little from 
the xmlpull interface to promoting xml pull parsing in general, 
including StAX. XPP could be used to evaluate new features for 
high-performance parsing, kXML for the needs of the mobile world.


I think we should position XmlPull.org in the future

- as a maintenance resource for the existing xmlpull interface

- for general Pull parsing promotion/education (including StAX);
   Sample code fragments may even work for both APIs w/o modification

- as a resource for discussing new ideas and concepts related
   to pull parsing

- as java namespace and project location of a free implementation of the
   event object API and Factories, based on the Stax XMLStreamReader.

- as java namespace and project location of StAX and XmlPull
   based utilities and samples such as
   - providing an XML stream from a DOM tree
   - a DOM builder
   - SAX adapter
   - JUnit tests


Perhaps we should also provide some general Java Pull parsing history 
information (timeline and stuff like that)?

I would like to position kXML 3 as a parser that

- provides implicit XML/HTML-tidy
- can be used on mobiles to process XML, HTML and WBXML.

I would like to re-architecture kXML 3 into two parsers (XML/WBXML), 
providing a common interface (stax/xmlpull intersection) without 
namespace support. Currently, the situation is not ideal, for instance I 
  have duplicated some code for an extremely simple parser (w/o 
namespaces, org.kobjects.xml.XmlReader). Also, namespace processing 
makes the WBXML code less readable. Actual XmlPull and StAX 
implementations will add namespace processing capabilities and delegate 
calls to one of the simple parsers.

Best regards,
Stefan











------------------------ Yahoo! Groups Sponsor ---------------------~-->
Yahoo! Domains - Claim yours for only $14.70
http://us.click.yahoo.com/Z1wmxD/DREIAA/yQLSAA/2U_rlB/TM
---------------------------------------------------------------------~->

 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
     http://groups.yahoo.com/group/xmlpull-dev/

<*> To unsubscribe from this group, send an email to:
     [email protected]

<*> Your use of Yahoo! Groups is subject to:
     http://docs.yahoo.com/info/terms/