Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] Element. // Used for XPath and serialization Why is Element.getNamespacePrefixesInScope() private?

xom-interest AT lists.ibiblio.org

Subject: XOM API for Processing XML with Java

List archive

Chronological Thread  
  • From: Wolfgang Hoschek <wolfgang.hoschek AT mac.com>
  • To: Elliotte Harold <elharo AT metalab.unc.edu>
  • Cc: xom-interest <xom-interest AT lists.ibiblio.org>
  • Subject: Re: [XOM-interest] Element. // Used for XPath and serialization Why is Element.getNamespacePrefixesInScope() private?
  • Date: Mon, 23 Jan 2006 17:58:06 -0800


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.





Archive powered by MHonArc 2.6.24.

Top of Page