Mailing-List: contact general-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@ws.apache.org
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Apache Wiki <wikidiffs@apache.org>
To: Apache Wiki <wikidiffs@apache.org>
Date: Thu, 27 May 2010 18:43:00 -0000
Message-ID: <20100527184300.25312.30600@eos.apache.org>
Subject: 
 =?utf-8?q?=5BWs_Wiki=5D_Trivial_Update_of_=22Axis2/Requirements=22_by_new?=
 =?utf-8?q?acct?=

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Ws Wiki" for change=
 notification.

The "Axis2/Requirements" page has been changed by newacct.
http://wiki.apache.org/ws/Axis2/Requirements?action=3Ddiff&rev1=3D3&rev2=3D4

--------------------------------------------------

  As mentioned before this section discusses OM in detail
  =

  =3D=3D Use Cases =3D=3D
- Since usecases are again a vast section it is moved to a seperate page
+ Since usecases are again a vast section it is moved to a separate page
  See OM Use Cases Discussed in [[FrontPage/Architecture/OMUseCases]]
  =

- =3D=3D Axis summmits concensus on OM: =3D=3D
+ =3D=3D Axis summmits consensus on OM: =3D=3D
  =

  {{http://ws.apache.org/~hemapani/images/axiom.png}}
  =

@@ -60, +60 @@

  =

  Minuts of the Summit discussion about OM
  	1. We need to design a pull based Axis engine that do streaming (the sta=
rt)
- 	1. Handlers want to accsess the the message, there are two cases
+ 	1. Handlers want to access the the message, there are two cases
- 	 	* accsess the Headers
+ 	 	* access the Headers
- 		* accsess the body
+ 		* access the body
  	1. There are two problems
  		* Pull forget what read before
  		* Handlers like to have easier infoset like (DOM like) interface.
- 	1. Proposal 1 - Save Headers as DOM elements, the body is accsess via th=
e pull parser. If the handler read the body it is his responsiblity to set =
it back. (TEAM feel this is not enough .. we need to help the users more.)
+ 	1. Proposal 1 - Save Headers as DOM elements, the body is accessed via t=
he pull parser. If the handler read the body it is his responsibility to se=
t it back. (TEAM feel this is not enough .. we need to help the users more.)
- 	1. Proposal 2 - Store the Headers in DOM element, if the body is accsess=
ed only, the  complete body is converted to DOM. Later the pull event will =
generating travasaling the DOM. (if body not created the pull events read f=
rom the stream.) =

+ 	1. Proposal 2 - Store the Headers in DOM element, if the body is accesse=
d only, the  complete body is converted to DOM. Later the pull event will g=
enerating travasaling the DOM. (if body not created the pull events read fr=
om the stream.) =

  	(TEAM feel the fact the complete body parsed when only the part of it ma=
y be need is not good)
  	1. Proposal 3 - OM, OM is a representation of the SOAP Message. =

- 		* provide accsess to the pull events =

+ 		* provide access to the pull events =

  		* provide a easy to accessible infoset
  		* Differed parsing as much as possible
- 		* cached the already readed information insome form so that thy can be =
re produce in need.
+ 		* cached the already read information in some form so that thy can be r=
e produce in need.
  		=

  =3D=3D Goals of OM =3D=3D
- 	OM is a Streaming XML infoset representation of the SOAP Message. It giv=
es the polymophic behaviour of ability to act as a pull event generater and=
 DOM like tree model at same time. =

+ 	OM is a Streaming XML infoset representation of the SOAP Message. It giv=
es the polymorphic behaviour of ability to act as a pull event generator an=
d DOM like tree model at same time. =

  =

   =3D=3D=3D It should support the following use cases =3D=3D=3D
  	        {{http://ws.apache.org/~hemapani/images/OMusecases.png}}
  =

   =3D=3D=3D It should support following requirements =3D=3D=3D
- 		1. Deffered the parsing as much as possible/ Streaming
+ 		1. Deferred the parsing as much as possible/ Streaming
  		1. Performance - Low memory usage, speed
  		1. Href support
  		1. MTOM support
@@ -93, +93 @@

   1. What is PULL interface, is it StAX+, Typed pull parser interface. =

   1. what is the OM XML infoset, DOM, JDOM like, our own =

   =

- =3D=3D Issue outside the direct scope of OM, but relevent =3D=3D
+ =3D=3D Issue outside the direct scope of OM, but relevant =3D=3D
   	How the encoding work? (It should handle by the encoding module), the m=
odule work on top of OM
  	Pluggable data binding =

  		since OM expose the Pull interface
@@ -156, +156 @@

  Streaming Tree Walking - this is incremental XML Tree (like Python PullDo=
m or XPP2 XmlPullNode) that has nodes is created on demand and deallocated =
when not needed
  =3D=3D Things to decide  =3D=3D
  =

-  =3D=3D=3D Does OM support serializing and deserialing  =3D=3D=3D
+  =3D=3D=3D Does OM support serializing and deserializing  =3D=3D=3D
  	* Option1 - OM support deserialize and serializing internally
  =

  	* Option2 - OM support DOM like XML infoset interface and Streaming inte=
rface, encoding is top of them
- 			Does this involving a performance panalty?
+ 			Does this involving a performance penalty?
  =

  			[As far as OM is concerned it is another model for an XML infoset and =
purely a representation of the underlying XML document. =

  		The difference is that it is lightweight and uses a pull model undernea=
th to get to the elements AS AND WHEN required. =

  		OM exposes onl two API's ,the DOM like API and the raw stream API (like=
 StAX). Ideally OM should hide its stream underneath but it is exposed for =
performance Reasons.
- 		(To allow handlers access the raw stream) So with this perspective I do=
nt think it is "clean" to have serilaizers and deserializers merged with OM.
+ 		(To allow handlers access the raw stream) So with this perspective I do=
n't think it is "clean" to have serilaizers and deserializers merged with O=
M.
  		They should be external components that access OM through the provided =
API's. =

  		if a different representation of OM is needed (like DOM3) it is provide=
d through a wrapper that does not necessarily duplicate OM objects but prov=
ide access to OM objects through a DOM interface.]
  		=

@@ -196, +196 @@

  =

  =3D=3D=3D General requirements ("boil ocean" ...) =3D=3D=3D
   * OM is lightweight XML Infoset model, currently aiming at subset of DOM=
 [lightweight]
-     - should we consider more Java specific or more XML Infoset friendly =
API? [java specific one is prefered, should be jDom like API -- Ajith]
+     - should we consider more Java specific or more XML Infoset friendly =
API? [java specific one is preferred, should be jDom like API -- Ajith]
   * Both read and write must be done =

-     - should there be read-only mode? (Lets accomodate this in to OM. Whe=
n handler accesses OM, deault is read only. if accessed by a provider, defa=
ult is not read only.)
+     - should there be read-only mode? (Lets accommodate this in to OM. Wh=
en handler accesses OM, default is read only. if accessed by a provider, de=
fault is not read only.)
   * Provide full access to XML Infoset representing SOAP message =

   * Provide access for rest of AXIS2 modules through internal OM API =

   * Provide access for rest of AXIS2 modules other XML APIs such as:
@@ -238, +238 @@

    *  Make sure XMLSecurity works over that DOM for encryption, decryption=
, signing and verification. This is at the XML level.
    * Has to have sufficient stuff to allow graph deserialization (for SOAP=
-Enc support)
  =

- =

-=20