Skip to Content.
Sympa Menu

xom-interest - RE: [XOM-interest] XPath Namespace Nodes rethink

xom-interest AT lists.ibiblio.org

Subject: XOM API for Processing XML with Java

List archive

Chronological Thread  
  • From: "Michael Kay" <mike AT saxonica.com>
  • To: "'Elliotte Harold'" <elharo AT metalab.unc.edu>, "'Wolfgang Hoschek'" <whoschek AT lbl.gov>
  • Cc: 'xom-interest' <xom-interest AT lists.ibiblio.org>
  • Subject: RE: [XOM-interest] XPath Namespace Nodes rethink
  • Date: Mon, 31 Jan 2005 21:52:55 -0000

> Namespaces are an ugly conceptual misfit, no matter how you approach
> them. Possibly I could avoid the problems by going back to
> the beginning
> and working namespaces into the Element class, so it use Namespace
> objects instead of strings, and modeling namespaces in scope
> like XPath
> does rather than namespaces declared like XOM does. But the
> memory cost
> still worries me. Much worse is the question of how to handle
> namespaces
> in scope as elements are moved around, disconnected from
> their parents,
> and inserted into new documents.

Modelling "inscope namespaces" rather than "declared namespaces" gives much
more predictable results from a user perspective: when elements are
disconnected from a tree and added to another tree, they take all their
inscope namespaces with them.

Of course, it's a challenge for the implementor, but if something is easier
for users and harder for implementors, then it's the right thing to do.

Modelling inscope namespaces as first-class nodes is a different question.
Most of the cost in implementing the XPath model of namespace nodes is not
because they're modelling inscope namespaces (rather than declared
namespaces), but because the nodes for each element have distinct identity,
document order, and parentage.

Saxon stores namespace declarations internally, but presents an
inscope-namespaces view to the user.

Michael Kay





Archive powered by MHonArc 2.6.24.

Top of Page