[jdom-interest] bug in Element() ?
Vamshi Reddy
Vamshi.Reddy at whn.com
Thu Sep 28 19:26:29 PDT 2000
How is it possible to add a child element at a given index?
Element.addChild(Element) inserts the element at the end of the list. There
is no method to specify the index.
To do this do we have to first create a new list and add the element at the
required index and continue to add the children? There must be a better way.
DOM parsers usually let you insert elements at any point in the list.
(Element.addChild(index, Element) -- index to insertAt?)
Is it possible to use the List.add() or with listIterator on a sync'd List
without an IllegalAddException?
org.w3c.dom has these operation in Node and ProcessingInstruction extends
Node. Shouldn't JDOM have something similiar at least? Is there a way to
manipulate the element through PI?
About setName(): An alternative given in the new docs is the setParent() but
you still have to first get the child of the old (parent) element, make a
new (parent) element and then setParent(). Still cannot think of a simple
reason why it was necessary to remove it. It does not make it any easier.
Thanks in advance,
Vamshi
-----Original Message-----
From: jdom-interest-admin at jdom.org
[mailto:jdom-interest-admin at jdom.org]On Behalf Of
jdom-interest-request at jdom.org
Sent: Wednesday, September 27, 2000 3:38 PM
To: jdom-interest at jdom.org
Subject: jdom-interest digest, Vol 1 #259 - 26 msgs
Send jdom-interest mailing list submissions to
jdom-interest at jdom.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.denveronline.net/mailman/listinfo/jdom-interest
or, via email, send a message with subject or body 'help' to
jdom-interest-request at jdom.org
You can reach the person managing the list at
jdom-interest-admin at jdom.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of jdom-interest digest..."
Today's Topics:
1. Re: Beta 5: SaxBuilder constructor crashes Hunter &
McLaughlin's code (Jason Hunter)
2. Re: Beta5 candidate (Jason Hunter)
3. (no subject) (Peter V. Gadjokov)
4. Re: (Jason Hunter)
5. RE: Beta5 candidate (Peter V. Gadjokov)
6. Re: Beta5 candidate (Jason Hunter)
7. RE: Beta5 candidate (Peter V. Gadjokov)
8. Re: Re: static data needs to be thread data for
multithreaded applications (Peter V. Gadjokov)
9. Iterator.remove() is calling a non-overloaded method to remove children
from an element. (Travers Waker)
10. Re: Beta5 candidate (Michael Engelhart)
11. RE: Re: static data needs to be thread data for
multithreaded applications (philip.nelson at omniresources.com)
12. No access to namespaces? (alan.quinton at autodesk.com)
13. RE: Iterator.remove() is calling a non-overloaded
method to remove children from an element. (Peter V. Gadjokov)
14. Re: Re: static data needs to be thread data for
multithreaded applications (Jason Hunter)
15. Re: Iterator.remove() is calling a non-overloadedmethod
to remove children from an element. (Jason Hunter)
16. RE: Iterator.remove() is calling a non-overloaded
method to remove children from an element. (Peter V. Gadjokov)
17. RE: Re: static data needs to be thread data for
multithreaded applications (Peter V. Gadjokov)
18. xml:lang Attribute problem (Perry Hoekstra)
--__--__--
Message: 1
Date: Tue, 26 Sep 2000 23:55:36 -0700
From: Jason Hunter <jhunter at collab.net>
To: "Michael F. Baker" <mfbaker at home.com>
CC: jdom-interest at jdom.org
Subject: Re: [jdom-interest] Beta 5: SaxBuilder constructor crashes Hunter
&
McLaughlin's code
> I just downloaded JDOM beta 5, and the SaxBuilder constructor
> line below crashes the application. Anyone have any ideas?
> Thanks!
> - Mike
What *exactly* does "crashes the app" mean?
-jh-
--__--__--
Message: 2
Date: Wed, 27 Sep 2000 00:02:15 -0700
From: Jason Hunter <jhunter at collab.net>
To: "Peter V. Gadjokov" <pvg at c-c-s.com>
CC: jdom-interest at jdom.org
Subject: Re: [jdom-interest] Beta5 candidate
> Could I get the serialization changes in? If so, how? I haven't
> had time to write a test-suite but it does work, I get the same
> trees out that I serialize.
Well, I wouldn't want to hold up beta5 for those changes. We're simply
too desperate to have a new milestone. On the other hand, getting them
into beta5 gives us an opportunity to test how well we migrate to
beta6. Exactly how far along are you? How substantial is the patch?
-jh-
--__--__--
Message: 3
From: "Peter V. Gadjokov" <pvg at c-c-s.com>
To: "'jhunter at collab.net'" <jhunter at collab.net>
Cc: "'jdom-interest at jdom.org'" <jdom-interest at jdom.org>
Date: Wed, 27 Sep 2000 00:22:03 -0700
charset="iso-8859-1"
Subject: [jdom-interest] (no subject)
>Well, I wouldn't want to hold up beta5 for those changes. We're simply
>too desperate to have a new milestone. On the other hand, getting them
>into beta5 gives us an opportunity to test how well we migrate to
>beta6.
Yep, I'd like to see it tested but no, I do not want to hold up a release.
As an aside, perhaps it's worth considering having somewhat more frequent
beta releases - the 'get it from cvs' is a very frequent response to bug
reports.
>Exactly how far along are you? How substantial is the patch?
I'm done, I've been sitting on it for a bit (since I sent out those perf.
numbers). The patch is small, writeObject and readObject methods are added
to all stored classes. I've tweaked Namespace a bit for better performance
but I'll take those changes out for the time being, the whole class is
likely to be rewritten by someone soon anyway.
The only other changes are a SerializationUtils class with a couple of
static methods to reuse the custom serialization of Namespace and List. Oh
and I've abstracted the lazy instantiation of the content and attribute
lists in Element to two private methods since the constant repetition of new
LinkedList() all over Element somewhat defeats the purpose of declaring the
ivar List. That change is also fair game for killing if it seems
inappropriate. That's it. Should I just mail c-diffs to the list?
-pvg
--__--__--
Message: 4
Date: Wed, 27 Sep 2000 00:45:55 -0700
From: Jason Hunter <jhunter at collab.net>
To: "Peter V. Gadjokov" <pvg at c-c-s.com>
CC: "'jdom-interest at jdom.org'" <jdom-interest at jdom.org>
Subject: [jdom-interest] Re:
> As an aside, perhaps it's worth considering having somewhat
> more frequent beta releases - the 'get it from cvs' is a very
> frequent response to bug reports.
Exactly! That's why I'm not holding up this one any.
> Should I just mail c-diffs to the list?
Yep. Make sure the utils class is package protected. (Even at that
it's unfortunate we'd need another class, even a support class, for
people to see in the package. Any way to do it elegantly without the
extra class?)
-jh-
--__--__--
Message: 5
From: "Peter V. Gadjokov" <pvg at c-c-s.com>
To: "'jhunter at collab.net'" <jhunter at collab.net>
Cc: "'jdom-interest at jdom.org'" <jdom-interest at jdom.org>
Subject: RE: [jdom-interest] Beta5 candidate
Date: Wed, 27 Sep 2000 01:17:20 -0700
charset="iso-8859-1"
>Yep. Make sure the utils class is package protected. (Even at that
>it's unfortunate we'd need another class, even a support class, for
>people to see in the package. Any way to do it elegantly without the
>extra class?)
I've put it in a org.jdom.util package but that's easy to change to org.jdom
and package protect it if that goes down better. It's not really a class,
just a couple of global functions. Their functionality can be explicitly cut
and pasted in the 3-5 places in which it is used. That's not 'elegant' in my
book but I'm not religious about it, I can make that change too, it will
just be a little more annoying to maintain in the future.
Here's what it looks like -
public class SerializationUtils
{
public static void writeList(List list, ObjectOutputStream out)
throws IOException
[...]
public static List readList(ObjectInputStream in)
throws IOException, ClassNotFoundException
[...]
public static void writeNamespace(Namespace ns, ObjectOutputStream out)
throws IOException
[...]
public static Namespace readNamespace(ObjectInputStream in)
throws IOException, ClassNotFoundException
[...]
}
And it gets called in places like this - Element.writeObject -
private void writeObject(ObjectOutputStream out) throws IOException {
out.writeInt(JDOM_ELEMENT_SVER);
out.writeObject(name);
SerializationUtils.writeList(attributes, out);
SerializationUtils.writeList(content, out);
SerializationUtils.writeNamespace(namespace, out);
}
I just grepped my tree, there are three call pairs from two classes to
write/read list and two call pairs from two classes to write/read namespace.
Let me know which way you'd prefer to see this go, I'll wrap it up and spew
to the list tonight (or shortly after I hear from you)
-pvg
--__--__--
Message: 6
Date: Wed, 27 Sep 2000 01:40:09 -0700
From: Jason Hunter <jhunter at collab.net>
To: "Peter V. Gadjokov" <pvg at c-c-s.com>
CC: "'jdom-interest at jdom.org'" <jdom-interest at jdom.org>
Subject: Re: [jdom-interest] Beta5 candidate
> public static void writeList(List list, ObjectOutputStream out)
> throws IOException
> [...]
> public static List readList(ObjectInputStream in)
> throws IOException, ClassNotFoundException
> [...]
Well, this could go in PartialList.
> public static void writeNamespace(Namespace ns, ObjectOutputStream
out)
> throws IOException
> [...]
> public static Namespace readNamespace(ObjectInputStream in)
> throws IOException, ClassNotFoundException
> [...]
> }
And this probably really should go in Namespace -- let the class take
care of its own serialization.
Using PartialList that way is probably just slightly less elegant for
us, but easier on the new JDOM user, and it's evened out by having
Namespace do its own internal management which I like in general
anyway. At least that's my 1:40am thinking.
-jh-
--__--__--
Message: 7
From: "Peter V. Gadjokov" <pvg at c-c-s.com>
To: "'jhunter at collab.net'" <jhunter at collab.net>
Cc: "'jdom-interest at jdom.org'" <jdom-interest at jdom.org>
Subject: RE: [jdom-interest] Beta5 candidate
Date: Wed, 27 Sep 2000 02:17:55 -0700
charset="iso-8859-1"
>Well, this could go in PartialList.
It could, it doesn't quite belong there since it stores any kind of List.
I'm not 100% sure but I think PartialList messes with the contract of the
List interface in ways that if you actually used this method to store a
PartialList, you won't get the exact same thing back when you read it, in
certain cases. But as I said, I'm not religious about it, it's a workable
solution, I'll go with it unless you've had a better 2:15am insight in the
interim.
>And this probably really should go in Namespace -- let the class take
>care of its own serialization.
Yeah, that's a better way. I should have thought of it but I already had the
utils class when I added that method. The Namespace thing can be taken care
of by standard means (readResolve/writeReplace/ObjectInputValidation
trickery) but I don't think that works on 1.1. Package protected statics in
Namespace are practically as good and more compatible. I think we have
consensus then.
I would be against holding up a b5 release to sort out the get Child/Element
issues. I think the API is likely to be affected by the next rev of
namespace handling. No matter what design we go with, it will have to be
able to represent namespace declarations, distinguish between namespace name
[info set term] and namespace decal. and perhaps even be able to do
in-scope tests. Such changes seem significant enough to likely affect our
views and the practical details of the traversal methods.
I'm putting with something else right now (a little JDOM-based utility to
make graphviz[http://www.research.att.com/sw/tools/graphviz/]
pretty-pictures of XML docs, I'll make it available if anyone else has a use
for it) but I'll make the serialization changes sometime tonight and email
them out. Thanks for the feedback.
-pvg
--__--__--
Message: 8
From: "Peter V. Gadjokov" <pvg at c-c-s.com>
To: "'jhunter at collab.net'" <jhunter at collab.net>
Cc: "'jdom-interest at jdom.org'" <jdom-interest at jdom.org>
Subject: Re: [jdom-interest] Re: static data needs to be thread data for
multithreaded applications
Date: Wed, 27 Sep 2000 02:53:46 -0700
charset="iso-8859-1"
>Yep. Weak references would come to the rescue. I added a note in the
>code to mark this as a future possibility. (I'm postponing action
>because it's potentially a lot of code and testing in an area that's
>been changing, and because weak refs don't work in JDK 1.1.)
My use of JDOM is also in server-world and I'd prefer to see a slightly
different direction - JDOM is a utility API so I think it should, as far as
possible, avoid making resource-management decisions for the API user and
when it does, it should provide hooks for as much control as feasible. In
the case of namespaces - assuming JDOM can one day tell between a namespace
name and a namespace declaration - Namespace declarations (or rather, their
prefix mappings) will probably be bound to a particular document so the
static data issue goes away there. If there is a big howl for memory sharing
between instances of docs with identical prefix mappings, the management of
that stuff can be opened up with an interface and you could optionally set a
prefix mapping manager delegate on docs. As to namespace names, I can't see
a good reason to keep these as global data either. There is no reason to go
through hoops to steal some CPU and save me some memory so I can do an
identity (==) comparison between namespace names. The comparison can be
optimized so it rarely has to do a full string comparison (and the URI
strings themselves can be interned for ==). For the memory-conscious, a
NamespaceName.intern() can be added.
Short'n'sweet - the static-data/sync problem is partially exacerbated by the
lack of separation between namespace name and namespace declaration and the
centralized storage of things that may not need centralized management under
a better model. Weak references alone are not a good option for serious
server-side use -I might (well, I do) want better control than that (say, a
configurable, explicitly bounded LRU cache that is based on weak
references).
-pvg
--__--__--
Message: 9
From: "Travers Waker" <traversw at innoforge.co.za>
To: <jdom-interest at jdom.org>
Date: Wed, 27 Sep 2000 12:56:01 +0200
charset="iso-8859-1"
Subject: [jdom-interest] Iterator.remove() is calling a non-overloaded
method to remove children from an element.
Hi.
Calling Element.getChildren() returns a "live" list that modifies the
original XML document tree. Whatever list JDOM returns obiviously has
overloaded methods for List.remove(Element name) to unset the pointer this
elements parent Element and perform other similar JDOM-specific tasks.
However, when one get's an Iterator for this List (i.e.
Element.getChildren().iterator()), the Iterator.remove() method calls a
method of the underlying list that is not overloaded to update the internal
fields of Element (e.g Element.parent). The following code illustrates the
problem: (The code just moves a child element from parent1 to parent2).
package tests.jdom;
import java.util.*;
import org.jdom.*;
class JdomListTest2 {
public static void main(String[] args) throws Exception {
Element parent1 = new Element("parent1");
Element parent2 = new Element("parent2");
parent1.addContent(new Element("child"));
List list = parent1.getChildren();
Iterator it = list.iterator();
Element child = (Element)it.next();
// list.remove(child);
it.remove();
parent2.addContent(child);
}
}
The error generated is:
org.jdom.IllegalAddException: The element "child" could not be added as a
child of "parent2": The element already has an existing parent "parent1"
at org.jdom.Element.addContent(Element.java:846)
at tests.jdom.JdomListTest2.main(JdomListTest2.java:20)
Exception in thread "main"
If I uncomment "list.remove(child)" and comment out "it.remove()",
everything works as expected. This is not as efficient as using
it.remove(), because list.remove(child) involves searching through the list
again for teh "child" element, even though the Iterator (it) is pointing to
exact location of child already!
Shouldn't be that hard to fix, but it would take a while to get familiar
with the JDOM code and CVS, so I think I'd better let someone who knows what
they're doing add support for Iterator.remove().
Thanks
Travers
--__--__--
Message: 10
Date: Wed, 27 Sep 2000 08:24:12 -0500
Reply-To: mengelhart at earthtrip.com
charset=us-ascii
From: Michael Engelhart <mengelhart at earthtrip.com>
To: jdom-interest at jdom.org, Jason Hunter <jhunter at collab.net>
Subject: Re: [jdom-interest] Beta5 candidate
Has the bug been fixed where attributes that have escaped string values get
unescaped upon parsing the XML document for beta 5? This has been driving
me insane but it doesn't appear that it has been fixed as of yet. Anyone
know?
Mike
--__--__--
Message: 11
From: philip.nelson at omniresources.com
To: jdom-interest at jdom.org
Subject: RE: [jdom-interest] Re: static data needs to be thread data for
multithreaded applications
Date: Wed, 27 Sep 2000 13:04:51 -0500
charset="iso-8859-1"
> My use of JDOM is also in server-world and I'd prefer to see
> a slightly
> different direction - JDOM is a utility API so I think it
> should, as far as
> possible, avoid making resource-management decisions for the
> API user and
> when it does, it should provide hooks for as much control as
> feasible. In
> the case of namespaces - assuming JDOM can one day tell
> between a namespace
> name and a namespace declaration - Namespace declarations (or
> rather, their
> prefix mappings) will probably be bound to a particular
> document so the
> static data issue goes away there.
Are you all thinking about using the getDocument to find locate the home for
the namespaces and or prefix mappings? At the time NameSpace was written,
there was a lot of discussion about the static hashtables but because nobody
wanted to maintain parent relationships, there was no way to put namespace
information in the Document for any given element. It seems this has
changed since then.
> Short'n'sweet - the static-data/sync problem is partially
> exacerbated by the
> lack of separation between namespace name and namespace
> declaration and the
> centralized storage of things that may not need centralized
> management under
> a better model.
I apologize in advance but I don't understand what you mean by "lack of
separation between namespace name and namespace declaration". I think that
the static variables in Namespace can't work on a server, or at least that
it's more compromises that it's worth. It does work in what I think would
have to be the more common use case of many similar xml documents processed
by a server app. My use case is a problem. I would think that
serialization would be complicated as well.
--__--__--
Message: 12
From: alan.quinton at autodesk.com
To: jdom-interest at jdom.org
Date: Wed, 27 Sep 2000 12:03:27 -0700
charset="iso-8859-1"
Subject: [jdom-interest] No access to namespaces?
Can anyone say why the B4 documentation provides access to the namespace
mappings while the actual code does not? Functions such as
getNamespaceURI(), getNamespaceMappings() are documented, but not
implemented in the jar file, or the code? Were these removed for a reason?
I need to get the URI associated with the prefix "" in the document so that
I can make a proper call to element.getAttribute(), I can't seem to find a
way to get this information...
Thanks in advance,
-Alan
--__--__--
Message: 13
From: "Peter V. Gadjokov" <pvg at c-c-s.com>
To: "'Travers Waker'" <traversw at innoforge.co.za>, jdom-interest at jdom.org
Subject: RE: [jdom-interest] Iterator.remove() is calling a non-overloaded
method to remove children from an element.
Date: Wed, 27 Sep 2000 12:40:03 -0700
charset="iso-8859-1"
>Shouldn't be that hard to fix, but it would take a while to get familiar
>with the JDOM code and CVS, so I think I'd better let someone who knows
what
>they're doing add support for Iterator.remove().
It might be a little harder to fix than it looks, most likely PartialList
will have to provide its own Iterator (or perhaps someone can write a
ListView-type class that does not replicate storage and is not so gory).
PartialList _does_ appear to override all the relevant methods and take care
of setting the parent to null. The trouble is that the ListIterator impl
inside LinkedList (the superclass of PartialList, the ListIterator impl is a
private class it defines) does not actually call LinkedList.remove(Object),
it calls
LinkedList.remove(Entry)
which is a private method and does all the work. PartialList never gets a
chance to get a method in edgewise. This is a little tricky to see in a
debugger because the private method is inlined in the ListItr
implementation. It's also not completely obvious from a quick glance at the
source since the type declaration of the 'lastReturned' ivar is no longer
visible in one's editor window. Isn't overloading fun?
In any event, the fix is worth thinking about some. It is also an
interesting datapoint in the 'is Element a List' debate - neither the person
who wrote the class nor the people who use JDOM (myself included) ever made
use of the 'live list' functionality enough to notice the issue :)
-pvg
--__--__--
Message: 14
Date: Wed, 27 Sep 2000 13:57:05 -0700
From: Jason Hunter <jhunter at collab.net>
To: philip.nelson at omniresources.com
CC: jdom-interest at jdom.org
Subject: Re: [jdom-interest] Re: static data needs to be thread data for
multithreaded applications
> At the time NameSpace was written,
> there was a lot of discussion about the static hashtables but
> because nobody wanted to maintain parent relationships, there was
> no way to put namespace information in the Document for any
> given element. It seems this has changed since then.
Elements can still exist unattached to a Document.
-jh-
--__--__--
Message: 15
Date: Wed, 27 Sep 2000 14:07:48 -0700
From: Jason Hunter <jhunter at collab.net>
To: "Peter V. Gadjokov" <pvg at c-c-s.com>
CC: "'Travers Waker'" <traversw at innoforge.co.za>, jdom-interest at jdom.org
Subject: Re: [jdom-interest] Iterator.remove() is calling a
non-overloadedmethod
to remove children from an element.
> It might be a little harder to fix than it looks, most
> likely PartialList will have to provide its own Iterator
> (or perhaps someone can write a ListView-type class that does
. not replicate storage and is not so gory).
Yep. It's not a trivial fix (thus it's in the TODO.txt file and not
already done in the code) but it's a pretty straightforward fix. I
suspect you could wrap a PartialListIterator around the ListItr normally
returned, and have it remove the elt from the backing list and then let
ListItr do its normal thing.
-jh-
--__--__--
Message: 16
From: "Peter V. Gadjokov" <pvg at c-c-s.com>
To: "'Jason Hunter'" <jhunter at collab.net>
Cc: "'Travers Waker'" <traversw at innoforge.co.za>, jdom-interest at jdom.org
Subject: RE: [jdom-interest] Iterator.remove() is calling a non-overloaded
method to remove children from an element.
Date: Wed, 27 Sep 2000 14:28:06 -0700
charset="iso-8859-1"
>I suspect you could wrap a PartialListIterator around the ListItr normally
>returned, and have it remove the elt from the backing list and then let
>ListItr do its normal thing.
What's the difficulty in having a predicated (filtered) sub-list class that
is just a plain wrapper around a List (any List, not just a LinkedList) as
opposed to the strange wrapper'n'subclass beast that PartialList is?
PartialList strikes me as hard to follow and wasteful, I'm sure there is a
reason for it but I can't figure it out.
-pvg
-----Original Message-----
From: Jason Hunter [mailto:jhunter at collab.net]
Sent: Wednesday, September 27, 2000 2:08 PM
To: Peter V. Gadjokov
Cc: 'Travers Waker'; jdom-interest at jdom.org
Subject: Re: [jdom-interest] Iterator.remove() is calling a
non-overloadedmethod to remove children from an element.
> It might be a little harder to fix than it looks, most
> likely PartialList will have to provide its own Iterator
> (or perhaps someone can write a ListView-type class that does
. not replicate storage and is not so gory).
Yep. It's not a trivial fix (thus it's in the TODO.txt file and not
already done in the code) but it's a pretty straightforward fix.
-jh-
--__--__--
Message: 17
From: "Peter V. Gadjokov" <pvg at c-c-s.com>
To: "'philip.nelson at omniresources.com'" <philip.nelson at omniresources.com>,
jdom-interest at jdom.org
Subject: RE: [jdom-interest] Re: static data needs to be thread data for
multithreaded applications
Date: Wed, 27 Sep 2000 14:31:40 -0700
charset="iso-8859-1"
>Are you all thinking about using the getDocument to find locate the home
for
>the namespaces and or prefix mappings? At the time NameSpace was written,
>there was a lot of discussion about the static hashtables but because
nobody
>wanted to maintain parent relationships, there was no way to put namespace
>information in the Document for any given element. It seems this has
>changed since then.
[...]
>I apologize in advance but I don't understand what you mean by "lack of
>separation between namespace name and namespace declaration". I think that
>the static variables in Namespace can't work on a server, or at least that
>it's more compromises that it's worth. It does work in what I think would
>have to be the more common use case of many similar xml documents processed
>by a server app. My use case is a problem. I would think that
>serialization would be complicated as well.
By 'separation' I mean having separate classes that represent what the
infoset calls 'namespace name' (basically, just the URI, a globally unique
id that distinguished one namespace from another, regardless of document
context) and a namespace declaration (a namespace, with a document-specific
prefix used for serialization and a document specific scope).
Namespace names need no centralized static storage. It could be useful if
you want to save memory and it allows identity comparison but the global
storage has other problems (concurrency issues, potential for unbounded
growth, etc).
Namespace declarations are document-specific so they need no centralized
storage either. The prefix map could live in Document. I think you are
raising the issue of getting the Document if you only have an element -
typically, an Outputter that cares most about prefixes gets the Document so
it doesn't have the problem. The recent change to isRootElement, though,
allows for the addition of a trivial getDocument method on Element which
would simply walk the path to the root until it hits the root element, if
any, and then return the root element's document.
So, what I'm talking about is this:
- A Namespace (or NamespaceName) class that is just the URI. This class has
a fast .equals method but does not rely on identity comparison. A sync'ed
Namespace.intern() method can be provided to trade performance for memory,
potentially, the parser can have an option to intern every NamespaceName it
encounters.
- A NamespaceDeclaration class that is typically stored in an Element. It
describes the binding of a prefix to a NamespaceName and the scope of the
Namespace (which is the inclusive scope of the Element).
- Facilities on Document and/or Element that let you
- look up the NamespaceName given a prefix and a scope (Element)
- find the in-scope (i.e. both declared and 'inherited'
declarations)NamespaceDeclarations of a given Element
- Magic that shuffles conflicting or redundant namespace declarations when
Elements are moved within or between Documents. This could end up being
somewhat slow. I'd say make it 'deferrable', i.e. allow (optionally?) NS
declarations to be 'out of sync' after a move until something like
Document.notmalizeNSDeclarations() is called.
If this covers the needs of NS handling (a big if, granted, but if it
doesn't I'm sure we'll hear about it), I don't think it actually needs
global static data anywhere.
-pvg
--__--__--
Message: 18
Date: Wed, 11 Oct 2000 08:59:57 -0500
From: Perry Hoekstra <dutchman at uswest.net>
Organization: Talent Software Services
To: jdom-interest at jdom.org
Subject: [jdom-interest] xml:lang Attribute problem
Greet the sun all:
I don't if this is how I implemented it or a bug but when I execute the
following code:
StringBuffer t_xml = new StringBuffer("<?xml version = \"1.0\"?>");
t_xml.append("<Foo xml:lang=\"en-US\"> ");
t_xml.append("</Foo");
org.jdom.input.SAXBuilder t_saxBuilder = new
org.jdom.input.SAXBuilder("org.apache.xerces.parsers.SAXParser");
org.jdom.Document t_jdomDocument = t_saxBuilder.build(new
java.io.StringReader(t_xml.toString()));
I receive the following exception:
org.jdom.JDOMException: The name "" is not legal for JDOM/XML
namespaces: Namespace URIs must be non-null and non-empty Strings..)
Now, looking at page 297 of the XML Bible, it states that xml:lang is a
valid attribute. I refresh my code with a fresh extract through CVS
this morning. Ideas on what I am doing wrong?
--
Perry Hoekstra
E-Commerce Architect
Talent Software Services
dutchman at mn.uswest.net
--__--__--
_______________________________________________
To control your jdom-interest membership:
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
t.com
End of jdom-interest Digest_______________________________________________
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