Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] Higher level namespace declarations for compactness

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: Tatu Saloranta <cowtowncoder AT yahoo.com>
  • Cc: Elliotte Harold <elharo AT metalab.unc.edu>, xom-interest AT lists.ibiblio.org
  • Subject: Re: [XOM-interest] Higher level namespace declarations for compactness
  • Date: Mon, 25 Sep 2006 00:52:03 -0700

On Sep 24, 2006, at 8:02 PM, Tatu Saloranta wrote:

--- Elliotte Harold <elharo AT metalab.unc.edu> wrote:

Tatu Saloranta wrote:

On a related note: it is still possible to get
proper
prefix rewriting on output (such that result is
output
with localName/URI pairs being correct and there
being
no prefix conflicts, which may require prefix
changes),

This should simply not be necessary. XOM does not
allow prefix
conflicts. If you can construct a document that
contains one using XOM,
then that's a bug; and I should fix it.

So much for that idea then. ;-)

One would expect a repairing and non-repairing Stax XMLStreamWriter impl to yield equal output (wrt. Canonical XML) when serializing XOM documents, because a XOM document is guaranteed to be wellformed due too XOM's hard coded internal sanity checks. On assembling an Element, XOM already rejects namspace conflicts with wellformedness exceptions. In XOM, assembling an element is a stage that precedes serialization. In the serialization stage there are no namespace conflicts anymore, and nothing needs to be repaired. Thus, repairing mode (a standard feature of StAX) offers no benefits for serializing XOM documents.

However, XOM offers no automatic assistance to generate a namespace- wellformed document in the presence of actual or potential namespace conflicts (it simly rejects them with an exception to begin with). So, it is the responsibility of the client to figure out how to resolve conflicts on element construction, if any.

In contrast, repairing mode is part of a later stage, namely serialization, and intended to relieve the (typically non-XOM) client of such responsibility. Repairing mode moves the burden of "fixing up" conflicting namespaces with non-conflicting namespaces into the serializer (XMLStreamWriter), thus generating ns wellformed documents no matter what conflicting namespace info the client passes to the StAX writer.

In practise, the absense of a repairing mode often seems to be a non- issue, but sometimes the safety of repairing mode comes in handy. In particular when multiple independent third party library modules are all writing to the same element or document.

Wolfgang.





Archive powered by MHonArc 2.6.24.

Top of Page