Current plan of action

  1. Start by implementing XmlInfoset as initial OM API

  2. Add support for DOM L2/L3 subset
  3. Determine memory footprint (cost of DOM wrappers) and evaluate performance of initial implementation
  4. Learn from prototype(s)

In general maintain some sets of tests so performance and memory usage are under control ...

Current issues (add more to the list)

  1. how to handle accessing event stream for SOAP : Body and avoiding building element tree for it?
  2. keeping OM API lightweight by using String directly instead of wrapper Text class (unless DOM Text node is requested)
    • Current OM implementations does not support this. But another prototype can be developed with this support, hopefully with a different implementation model. - Eran Chinthaka
  3. decoupling DOM API, allowing JDOM API and other APIs
    • This has been addressed in the Proposed OM API. Anyone can wrap the proposed OM API to get the required functionality. And this makes OM to achieve the required objectives. - Eran Chinthaka
  4. CDATA support even though it is not in XmlInfoset?

    • CDATA is not required if one is trying to wrap OM with DOM. But how about the other XML infoset implementation. I think its better if OM can have all the infoset preserved. Comments ... ? - Eran Chinthaka

Current work

Consequences:

Features of the Object Model (OM)

DOM ->OM and OM->DOM support

Are we need DOM2OM converter/wrapper if so implement it ASAP so other parts can be go forward using it.

Push API for serialization

This is a API that have a serializing methods which work like SAX. There are methods like writeStartTag(), writeEndTag(). The SerializationContext in the current Axis is implementation of this type of API. We may be able to use it.

FrontPage/Architecture/OMIssues (last edited 2009-09-20 22:48:45 by localhost)