[jdom-interest] Accessing Child Elements

[Peter V. Gadjokov]

[pvg] Element.getNamespace() should tell you what namespace an element
is
[pvg]_currently_ in, a new method is needed to query the namespace an
[pvg] element was explicitly declared in.

>What does that give you though?  I think a JDOM element should
>either have a namespace set (explicit namespace) OR it should 
>inherit the namespace of the parent (implied namespace).  The
>only issue is making sure that the namespace be maintained as
>an element is added / removed / cloned.

It doesn't give you an awful lot, other than being able to tell whether
an element is inheriting a namespace from its context or whether
it has an explicitly declared namespace. It lets you distinguish 
between what boils down to a 'dynamically typed' or 
'statically typed' element, dynamically typed elements being ones
that can be moved to a new context and aquire their type from it,
while retaining their structure. Having given it some further
thought, I've decided that this is not a concept worth supporting
and is most likely not the intent of the namespace specification. 
The namespace inheritence/scoping rules are an artifact of the
textual XML representation that need not be modelled in the Java API.


>	From what I understand about XML namespaces, they aren't
>lexically scoped which is why "boston" has the default namespace
>instead of "us" in this example: [...]

Yes, I should not have used such a specific term - I meant that
the scoping was 'lexical-like' with respect to the XML namespace
_declaration_, i.e. the declaration is the environment, not the 
element. If an element contains an unprefixed declaration, all
unprefixed sub-elements are in that namespace. 
To take this abuse of terminology a little further, I think what
you are  (and I was) describing amounts to the _ability_ to have
dynamic scoping when you want it by using the default namespace.
Why am I calling it dynamic? Because what it boils down is having
elements whose 'type' is not tied to some environment at time of
declaration (instantiation) but is defined by the environment it
is contained in at a given time. My motivation for proposing the
change was getting more sensible behaviour in the default,
namespaceless convenience methods, the scoping behaviour came 
out as a side effect. As I said, I've convinced myself that this
type of dynamic behaviour is undesirable in the Java API, it ends
up modelling something that I think is purely an artifact of 
the specification for textual representation. I do still want
getChild, new Element, etc to behave more consistently so I've
modified my proposal - I've proposed eliminating NO_NAMESPACE
as a distinguished namespace (by changing the default behaviour
of the convenience methods) and enforcing the notion of a unique,
immutable namespace declaration for every element (bound at
instantiation), both at runtime and when serialized. I think it
clarifies the API semantics, makes the convenience methods behave
more predictably/usefully and is in the spirit of the current 
implementation - there are no complex scoping rules. That framework
can still support utility methods to ease moving/copying an element
to a different document with a different namespace or even tag name.

[Since I started the whole language terminology abuse, I'll take
the irrelevant analogies further - I think what you're/I was 
asking for is the ability to have 'structural' vs 'name' type 
equivalence. I.e. if two element 'types' (namespace+tagname) are 
structurally equivalent, you want to be able to use them in
different contexts and not worry about re-specifying the type 
explicitly. Java/C++/Pascal/most other statically typed languages
rely on name type-equivalence (structurally identical types
with different names are  considered different types), the model
is intuitively familiar to most and I think JDOM should continue
to emulate it when it comes to Elements and Namespaces. 
Even-more-irrelevant-aside - Modula 3 (of, uhm, cvsup fame :)
is statically typed and  has structural type equivalence]

-pvg