FrontPage/Architecture/OMIssues

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

• Alek: Revised OM API

• Ajith, Chinthaka, Dasarath, Deepal: OM API

• Dasarath’s implementation (Doubly linked lists for siblings, JDOM like api and removing tight DOM integration from the OM Model) SVN

• Ajith implementation (the column like table model found in Xalan DTM onto a JDOM like API) SVN

• Chinthaka’s Implementation (Dasarath’s implementation by improving children traversal model) SVN

• DEPRECATED? Ajith, Chinthaka, Dasarath, Deepal: Implementation of OM Table Model

Consequences:

• All headers are always available as OM (or pull)
• If access to the full body OM is desired (in response handlers, for example) then a request handler must ask for the full OM to be populated (probably with a specific API: om.fillThySelf()). Otherwise the body stream is consumed by the provider and gone forever (if the provider reads the body stream using the pull API and not the OM API).

Features of the Object Model (OM)

• Design AXIOM interfaces as a subset of DOM (the subset needed for XMLSecurity DOM stuff). However the interfaces are standalone: org.apache.axis.axiom (?? should axiom be on its own: its really just an efficient tree model over a pull stream)
• Implement a DOM to push serializer and maybe also DOM to OM
• Make sure XMLSecurity works over that DOM for encryption, decryption, signing and verification. This is at the XML level. Note that both read and write must be done
• MTOM impact: be able to support MTOM (keep data as base64, data handlers and other stuff).
• Provide data binding hooks to allow one to ask for XML chunks in mapped types. For complex types a deserialization environment must be provided. That will be an interface via which a deser environ can be plugged in. Has to have sufficient stuff to allow graph deserialization (for SOAP-Enc support)
• Stores only the portions read. Rest is in the original stream

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.

• ability to convert it DOM
• access it as the Pull stream
• Support all the security handler scenarios

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.