[jdom-interest] JDOM && Jaxen
Szegedi Attila
szegedia at freemail.hu
Thu Aug 2 08:08:46 PDT 2001
The XPath spec says that (quote)
"Each element has an associated set of namespace nodes, one for each
distinct namespace prefix that is in scope for the element (including the
xml prefix, which is implicitly declared by the XML Namespaces
Recommendation [XML Names]) and one for the default namespace if one is in
scope for the element. The element is the parent of each of these namespace
nodes; however, a namespace node is not a child of its parent element.
Elements never share namespace nodes: if one element node is not the same
node as another element node, then none of the namespace nodes of the one
element node will be the same node as the namespace nodes of another element
node. This means that an element will have a namespace node:
- for every attribute on the element whose name starts with xmlns:;
- for every attribute on an ancestor element whose name starts xmlns: unless
the element itself or a nearer ancestor redeclares the prefix;
- for an xmlns attribute, if the element or some ancestor has an xmlns
attribute, and the value of the xmlns attribute for the nearest such element
is non-empty"
This definition (which, IMHO should be part of the XML InfoSet spec rather
than the XPath spec) clearly speaks against flyweights. OTOH, flyweight
Namespaces are really practical, moreso as they carry the philosophy of a
namespace being a unique, standalone entity (as it is an URI) and not tied
to any particular Element instance - I definitely like it that way, not to
speak about the memory overkill of having one namespace object per namespace
per element...
I have a suggestion: Namespace class could have flyweight and "localized"
instances (those that are being tied to particular Element, hence have a
concrete location). We could introduce an "Element parent" field and
associated accessors to it. The flyweight instances would have null parent.
The Element could have getLocalizedNamespace() and
getLocalizedNamespace(String) in addition to getNamespace() and
getNamespace(String) that would return a NEW localized namespace on each
call constructed to be identical to the flyweight, only with parent set to
"this" element. This way it wouldn't create burden on memory and CPU in
typical JDOM usage, but if someone uses XPath with namespace expressions
they'll be available in form of short-lived temporary objects.
Attila.
----- Original Message -----
From: "Jason Hunter" <jhunter at acm.org>
To: "bob mcwhirter" <bob at werken.com>
Cc: <jdom-interest at jdom.org>
Sent: 2001. augusztus 1. 21:06
Subject: Re: [jdom-interest] JDOM && Jaxen
> bob mcwhirter wrote:
> >
> > Yah, even without getParent(), though, not using flyweights on the
> > Namespaces would help.
>
> Really, why?
>
> > In a given document, how many times do you typically see the exactly
> > same namespace decl? Is it worth the overhead of flyweighting them?
>
> JDOM stores namespaces in each element (so when they move they keep
> their namespace). This means it's not just the decls that matter.
> Imagine a namespace-aware document with 10,000 elements in 3
> namespaces... With the current model you'll have 3 Namespace instances.
> With a non-flyweight you'll have between 3 and 10,000 depending on
> usage. And with a non-flyweight with parents, you'll for sure have
> 10,000. The reason the middle choice varies is that if the builder
> (class or programmer) is at all smart, they can reuse namespace
> instances with a private factory instead of the public one used now. If
> parentage must be retained, no reuse is possible.
>
> -jh-
> _______________________________________________
> To control your jdom-interest membership:
>
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
t.com
>
More information about the jdom-interest
mailing list