XOM API for Processing XML with Java

[Wolfgang Hoschek <wolfgang.hoschek AT mac.com>]

On Jan 23, 2006, at 5:34 PM, Elliotte Harold wrote:

> Wolfgang Hoschek wrote:
>
> > Anything that converts an external XML representation from/to XOM  
> > requires efficient support for namespace iterations. Like the  
> > nu.xom.Serializer or DOMConverter or SAXConverter, or the  
> > streaming serializers, the bnux serializer or the STAX converters,  
> > or any number of other things connecting to Axis AXIOM, XFire,  
> > JAXB, JixB, etc, etc.
>
> No, I don't think it is. Needing namespaces *in-scope* is a very  
> weird thing and purely relevant to XML and things that try to be  
> XML but aren't.

I was referring to all namespaces defined on an element, not the  
namespaces in-scope. In-scope namespaces are a separate issue (and  
personally less of an itch to me), but if one were to contemplate a  
new abstraction for various common namespace iteration flavours in an  
easy, safe and efficient way (e.g. some form of custom Iterator), one  
might as well keep those in mind as well.

> I don't think generic data binding frameworks and serialization  
> into other frameworks actually need to inspect or preserve this  
> information. SAXConverter/DOMConverter, OK, maybe. They need to do  
> this, but those aren't what I think of as speed-critical operations  
> (especially DOMConverter). They're there for convenience, not speed.

They'd better be efficient or else they'll most likely be one of the  
primary XML related hotspots.

> The part of XML that is potentially relevant (and not always then)  
> when converting to something that's not XML is the namespace of  
> each element and attribute, and this can be cleanly and efficiently  
> managed without much effort. The problem only arises if you really  
> want to preserve all namespaces in scope, including those declared  
> as additional namespaces.

Yes, and that's what I'm doing all the time in a large variety of  
contexts.

> I've yet to see a use-case that needs to iterate over those  
> additional namespaces other than alternate representations of XML.

As already mentioned, there are countless alternate representations  
of XML, with the obvious corresponding usecases.

> Alternate representations of non-XML data models (JAXB, JibX, etc.)  
> don';t need this.

Those are typically bridged via STAX, so they indirectly need this as  
well.

> I still think this is on the wrong side of 80/20.

Not if you'd like to enable better integration of XOM with the rest  
of the world, a critical condition for it's long term survival.

Wolfgang.