Two methods OMSE.getNamespace() and OMSE.getLocalName() do not involve expansion to avoid the expansion as late as possible. Typical XML processor checks localname and namespace URI first, then decides whether it should process the sub-tree or not. Caching Localname and Namespace is smart way for lazy evaluation.
2008/7/2, Nicholas L Gallardo <[EMAIL PROTECTED]>: > > That doesn't necessarily make sense to me. If all we want to know is > possibly the namespace/localname of the element, then we've blown out all > the of the content of the OMSourcedElement. > > So for instance, anyone that just checks the QName of the element on an > outbound flow for JAX-WS is going to blow out the element. That eliminates > the performance gains of writing to the outbound stream as late as possible. > > Takahide, I see your point. There is potential for inconsistency with the > way prefixes are returned. > > The problem is that not all sources of OMSourcedElements can know ahead of > time what the root element prefix is going to be. For example, if your OMSE > is backed by JAXB then there's no way to specify what that prefix is going > to be in the JAXB Marshaller. Because of that, we're at the mercy of what > JAXB returns. > > Regards, > > -Nick > > > [image: Inactive hide details for Davanum Srinivas <[EMAIL PROTECTED]>]Davanum > Srinivas <[EMAIL PROTECTED]> > > > > *Davanum Srinivas <[EMAIL PROTECTED]>* > > 07/02/2008 07:52 AM Please respond to > [email protected] > > > To > > [email protected] > cc > > > Subject > > Re: [AXIOM] Prefix mismatch of OMSourcedElement > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Takahide, > > Does it make sense to trigger the expanion when getNamespace() is called? > > thanks, > dims > > Takahide Nogayama wrote: > | Hi folks, > | > | I am facing prefix mismatch problem of OMSourcedElement. If we get a > | prefix from non-expanded OMSE by using OMSE.getNamespace().getPrefix(), > | the returned prefix is "". But if we get the prefix from expanded OMSE, > | then the returned prefix is "ns1". The first default OMNamespace is set > by > | OMSE creater (can be outside of axiom and axis2) through constructor > | argument, The second OMNamespace is created from OMDatasource when it is > | expanded. Since these two OMNamespace are created by different ways, the > | prefixes can be mismatch. > | > | OMSourcedElement should return the same data regardless of whether it is > | expanded or not. I think the OMNamespace should not be provided by > | Constructor, but should be provided by OMDataSource to avoid such prefix > | mismatch, otherwise we have to expand OMSourcedElement when > getNamespace() > | is invoked. I am not sure there are other ways to avoid this problem... > | > | Let me know your comments. > | > | Regards, > | --------------------------- > | Takahide Nogayama, IBM Tokyo Research Laboratory > | E-mail: [EMAIL PROTECTED] > | --------------------------- > | > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQFIa3nwgNg6eWEDv1kRAkPDAJwLFZdNGDxZCM4Dw3fjlX8tBi1QSgCePtc0 > JWecKvm+rRNlmAjm+flSJNA= > =ztK8 > -----END PGP SIGNATURE----- > >
