axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Wiedmann <jochen.wiedm...@freenet.de>
Subject Re: [Axis2][OM] representing XML Infoset
Date Wed, 15 Sep 2004 12:45:16 GMT
Srinath Perera wrote:

>  1) parser that read the data as late as possible. (e.g. if the xml
> message has 100 elemnts and user ask for the 3 only the object model
> created for three elements at the memory). So the memory usage is
> efficent as possible.
>  2) A infoset that provide DOM like accsess and ability generate pull
> event from the ssame infoset objects. When the pull event are required at
> the provider and what ever events not read in to memory so far will be
> served from the  stream.
>  3)  OM should support DOM directly or indirectly (support for secuity)...
> I think alek create the interface based on the XML infoset spec. We got
> to discuss how to imporve it. Implementing DOM will make internal model
> too complex. (It may be clean to have simpler interface and wrapped it in
> need.. we are checking the possibliliy.. )

It is of course desirable to read the data as late as possible. That 
also suggests the use of a pull parser. So far I agree 100%.

However, if the rationale is to support the things that you describe 
above, then I find the published interface by far overfeatured. I'll 
explain my thoughts in the case of the following XML document:

    <soap>
       <soap-header>
       </soap-header>
       <soap-body>
           <object1/>
           <object2/>
           <object3/>
           ....
           <object687236487623424323423/>
       </soap-body>
    </soap>

Processing this document is obviously happening in two completely 
different stages. In the first stage, semantics are very important. In 
the second stage, a low memory profile matters.

If I understand things right, then the OM, as it now is, suggests, that 
while processing object8768763284, then I will always have access to
object1, and even to the SOAP header. (Note, I am talking about back 
references here! The pull parser only helps for forward references!)

If you disable the possibility, to forget object1 while processing 
object2, then you'll repeat the faults of Axis1.

As a consequence, I would propose the following changes:

- No backward references; if backward references are required,
   then the information has to be stored. (For example, in the
   case of the SOAP header), this might mean that the complete
   SOAP header might be stored. Note, that stored information
   might implement an extended, or completely different interface,
   including backward references.
- No downward references, except for the first child. Additionally,
   specify that using the forward reference disables access to the
   downward reference.
- Remove all possibilities to *change* the objects. The purpose is
   to provide information. Nothing more, nothing less. Of course,
   the pull parser needs setters, and the like. However, that is
   a matter of implementation.
- The only exception for changes: Allow to provide a factory, that
   is used by the pull parser. In other words: If you actually need
   extended possibilities like backward references, you may get them
   by casting to the objects created by your factory. For example,
   a factory creating DOM documents could be shipped. Likewise, a
   factory creating JAXB or Castor objects.

Jochen


-- 
http://lilypie.com/baby1/050423/1/5/1/+1

Mime
View raw message