[jdom-interest] Re: jdom-interest digest, Vol 1 #1157 - 5 msgs
Peter.H.Roberts at bbh.com
Peter.H.Roberts at bbh.com
Mon Mar 17 05:33:21 PST 2003
I have been using JDOM for a few years now, I would like to contribute if I can, like Jason coding for a living leaves little free time, but jdom is great.
Peter:)
jdom-interest-reque
st at jdom.org To: jdom-interest at jdom.org
Sent by: cc:
jdom-interest-admin Subject: jdom-interest digest, Vol 1 #1157 - 5 msgs
@jdom.org
03/17/2003 02:04 AM
Please respond to
jdom-interest
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: Is JDOM dying? (Jason Hunter)
2. Re: Is JDOM dying? (AH)
3. Character escaping (Alex Rosen)
4. Re: Is JDOM dying? (Bradley S. Huffman)
5. Re: Character escaping (Bradley S. Huffman)
--__--__--
Message: 1
Date: Sun, 16 Mar 2003 11:48:17 -0800
From: Jason Hunter <jhunter at servlets.com>
To: malachi at tremerechantry.com
Cc: jdom-interest at jdom.org
Subject: Re: [jdom-interest] Is JDOM dying?
There's two ways to look at an XML model. One is classes which simulate
the XML text representation. Another is classes which simulate the
fundamental structure and meaning of the XML. JDOM has decided to model
the meaning, not the text, and has done so correctly. We're not going
to change.
We chose to model the "meaning" for many reasons. There are arguments
for going the other way, but they weren't (and still aren't) as
compelling.
Now, I do think within the "meaning" model it would be handy to have an
elt.getChild("foo") that didn't require always passing in the same old
namespace like elt.getChild("foo", SAMEOLDNS). That's what trips up
most people. Unfortunately we shouldn't treat no namespace the same way
as a parent namespace. It's inconsistent. One option is to have a
wildcard like elt.getChild("foo", ANY) which follows the XQuery (XPath?)
precedent of using a * to match any namespace such as
/*:foo/*:bar/text(). But is ANY better than SAMEOLDNS? Not really.
-jh-
--__--__--
Message: 2
From: "AH" <ahives at hotmail.com>
To: "Jason Hunter" <jhunter at servlets.com>,
"Frank Cohen" <fcohen at pushtotest.com>
Cc: "Jason Long" <jason at supernovasoftware.com>,
"JDOM" <jdom-interest at jdom.org>
Subject: Re: [jdom-interest] Is JDOM dying?
Date: Sun, 16 Mar 2003 12:19:13 -0800
Hello all...I would like to help on coding but don't know how to get
started...please, someone stir me in the right direction so that we can get
this 1.0 out and running...Frankly, I am a little tired of all the APIs that
are being proposed to ultimately do the same thing...It is very confusing to
those newbie's wanting to get started in XML processing and those who want
to simplify there work by concentrating on one API...I mean we got: JDOM,
DOM4J, SAX, DOM, XOM, JAXB, blah, blah, blah...Even though I have not tried
all these APIs I am sure they are all good but this thread is for JDOM so
lets keep it that way...JDOM, or any of the other APIs for that matter, will
never be a cure all to the problems of us developers so let us keep this in
mind...I use multiple parsers and APIs in programs that work with XML...I
find it empowering to be able to use combinations of APIs to do certain
things...All these APIs have a specific purpose and I say let them serve
that purpose...It is better to each API do a couple things really well then
do everything mediocre...For instance, I am sure you developers have used a
combination of Sockets, XML/JAX-RPC, RMI, EJB, Servlets, JSP, or SOAP all in
the same application before or either two at the same time...Why? After all
they all have the same intention in mind, which is to communicate via a
network connection, and can do the same as the others...But they all have
there advantages and disadvantages...There are certain instances where using
one specific API exclusively will be less advantageous than using a
combination of those even though at times it may get a little complex
dealing with the intricacies and nuances of each API...This is nothing new
and is the same for all APIs even the XML ones...I know JDOM has been a
little sluggish for some time now but lets not lose sight on the advantages
of JDOM...Instead of contemplating its death let use put some life back into
it...I would like someone to tell me what type of new functionalities are
needed so that developers such as myself, who are eagerly anticipating such
action, can get this thing rolling again...
AH
----- Original Message -----
From: "Frank Cohen" <fcohen at pushtotest.com>
To: "Jason Hunter" <jhunter at servlets.com>
Cc: "Jason Long" <jason at supernovasoftware.com>; "JDOM"
<jdom-interest at jdom.org>
Sent: Friday, March 14, 2003 9:28 AM
Subject: Re: [jdom-interest] Is JDOM dying?
> Hey Jason: Thanks for your contribution of JDOM. I find it very useful
> in my work with Web Services. I very much appreciate your efforts.
>
> The plan you put makes sense to me. When you post the list of actions
> I'll look to see if I can volunteer some code/patches.
>
> Once 1.0 is done then let's talk about me being lead on the JCP process.
>
> -Frank
>
>
> On Wednesday, March 12, 2003, at 12:00 PM, Jason Hunter wrote:
>
> > I could write a long paper on the lifecycle of JDOM and probably will
> > someday. The short summary appropos to your concerns is that after I
> > went self employed a little over a year ago, my free time dried up. I
> > offered JDOM stewardship to a few individuals, but they declined.
> > Laurent and Brad are still energetic and great coders and have fixed
> > any
> > bugs as they've appeared, but the project's been going without a strong
> > rudder. I realize we need to get to a 1.0 and have been trying to
> > arrange my schedule to help lead that. I think as part of that we'll
> > drop some of the pie-in-the-sky ideas and just concentrate on the last
> > bit of spit and polish. Finalize everything so people can rely on it
> > and be happy.
> >
> > Here's my plan:
> > 1) I'll propose a new TODO.txt based on what's there now and what's
> > flagged in my inbox
> > 2) We'll solicit feedback for anything else that needs to be in 1.0
> > 3) We'll divide the items into well-defined, concrete actions
> > 4) People can volunteer to perform the actions
> > 5) When all actions are done we'll manage the 1.0 release
> >
> > As far as the JCP goes, I think it's more important with limited
> > resources to get a 1.0 software release out. To push JDOM through the
> > JCP process would require a volunteer to lead it.
> >
> > -jh-
> >
> >> I have been using JDOM for some time, and I have noticed the following
> >> problems:
> >>
> >> 1. There seems to be no desire to have a new release or even talk
> >> about it.
> >> 2. There hasn't been any update to the web site in a year.
> >> 3. Very few messages are posted to this list.
> >>
> >> I enjoy using JDOM, if fact my project rely heavily on it.
> > _______________________________________________
> > To control your jdom-interest membership:
> > http://lists.denveronline.net/mailman/options/jdom-interest/
> > youraddr at yourhost.com
> >
> >
> --
> Frank Cohen, Founder, PushToTest, http://www.PushToTest.com, phone: 408
> 374 7426
> Come to PushToTest for free open-source test automation solutions that
> test and monitor
> Web-enabled applications, especially Web Services for scalability and
> reliability.
>
>
> _______________________________________________
> To control your jdom-interest membership:
>
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
t.com
>
--__--__--
Message: 3
Date: Sun, 16 Mar 2003 13:49:54 -0700
From: "Alex Rosen" <arosen at novell.com>
To: <jdom-interest at jdom.org>
Subject: [jdom-interest] Character escaping
I was bored this afternoon, so I started looking at the output-escaping
problem mentioned in the TODO list.
The problem is how to determine which characters need to be escaped (by
character references like "ꯍ") for a particular encoding. In JDK
1.4, java.nio.charset.CharsetEncoder can do this for us, but we still
need to be able to run on pre-1.4 systems. My idea is to have an
interface called EscapeStrategy (see below). We can have an
NioEscapeStrategy implementation class that uses CharsetEncoder.
XMLOutputter will attempt to soft-load that implementation (using
Class.forName). If that fails, it will fall back to another
implementation that works on all systems. This BasicEscapeStrategy will
allow the following characters to pass through unescaped:
All characters, for UTF-8 and UTF-16.
8-bit characters, for ISO-8859-1 (Latin-1)
7-bit characters, for all other encodings
All other characters are escaped. So we'll never output a bad character
(one that can't be encoded in the current charset), but we might encode
more characters than we need to, if you're using a pre-1.4 Java and
you're not using UTF-8 or UTF-16 or Latin 1. Oh well.
The first issue is that, while we'll still be able to run on pre-1.4
systems, we won't be able to compile on them, unless they manually
delete the NioEscapeStrategy.java file first.
The second issue is with characters > 16 bits, which I understand only
partially. (Elliotte you'll have to help me out here.) It seems that
Java doesn't fully support this now, since there's a JSR to add support
for them in JDK 1.5. Presumably this support will use surrogate pairs,
where it takes two Java chars to represent these new Unicode characters.
But CharsetEncoder in 1.4 seems to take this into account, it talks
about surrogate pairs. I guess this API was written with the future in
mind, for when Java does fully support them?
Anyway, assuming that I've got all that right... Exposing surrogate
pairs in the EscapeStrategy interface would complicate it, and probably
make it much less efficient (since CharsetEncoder deals with surrogate
pairs only when you pass in a CharSequence). Instead, I think we can
decide to always encode characters > 16 bits. This doesn't seem like
much of a limitation, since the output will still be correct - it just
might be inefficient if you're using UTF-8 and your document contains
lots of musical symbols or Old Italic. So XMLOutputter would check for
surrogate pairs (by checking for chars between D800 and DFFF), and would
go ahead and encode them, rather than asking the EscapeStrategy. Sound
OK?
Alex Rosen
Novell, Inc.
P.S. Hmm, I just noticed that TODO says that Brad has a suggested
solution. Didn't mean to step on anyone's toes. Was this on the mailing
list somewhere?
/**
* This interface tells XMLOutputter if a particular character should
* be "escaped", by outputting a character reference (e.g.
"墡")
* instead of the actual character (e.g. the char whose value is
0x58A1).
* Commonly, characters that can't be expressed natively in the
specified
* encoding will escaped.
*/
public interface EscapeStrategy
{
/**
* Called to inform us of the encoding that is being used.
*/
public void setEncoding(String encoding);
/**
* Return true if this character should be escaped. Note that the
following
* types of characters are automatically escaped, and are not
passed in to
* this method:
* <ul>
* <li>Characters that must be escaped because of the XML rules
* (e.g. ampersands, or quotes in attributes)
* <li>Characters larger than 16 bits (represented in Java by
* surrogate pairs)
* </ul>
*/
public boolean shouldEscape(char ch);
}
--__--__--
Message: 4
To: Jason Hunter <jhunter at servlets.com>
Cc: jdom-interest at jdom.org
Subject: Re: [jdom-interest] Is JDOM dying?
Date: Sun, 16 Mar 2003 19:27:46 -0600
From: "Bradley S. Huffman" <hip at a.cs.okstate.edu>
Jason Hunter writes:
> Now, I do think within the "meaning" model it would be handy to have an
> elt.getChild("foo") that didn't require always passing in the same old
> namespace like elt.getChild("foo", SAMEOLDNS). That's what trips up
> most people. Unfortunately we shouldn't treat no namespace the same way
> as a parent namespace. It's inconsistent.
If anything I'd get rid of all methods that default to no namespace so that
one always specifies a namespace, even if it is always NO_NAMESPACE. Sure
it a few more characters but then there is no ambiguity about what is
actually meant. Never sacrific characters for clarity :)
> One option is to have a
> wildcard like elt.getChild("foo", ANY) which follows the XQuery (XPath?)
> precedent of using a * to match any namespace such as
> /*:foo/*:bar/text(). But is ANY better than SAMEOLDNS? Not really.
Filters :)
Brad
--__--__--
Message: 5
To: "Alex Rosen" <arosen at novell.com>
Cc: jdom-interest at jdom.org
Subject: Re: [jdom-interest] Character escaping
Date: Sun, 16 Mar 2003 19:33:11 -0600
From: "Bradley S. Huffman" <hip at a.cs.okstate.edu>
"Alex Rosen" writes:
> P.S. Hmm, I just noticed that TODO says that Brad has a suggested
> solution. Didn't mean to step on anyone's toes. Was this on the mailing
Looks like we have basically the same thing.
Brad
package org.jdom.output;
/**
* Mapping of characters that should be formatted as character entities.
*/
public interface CharFormat {
/**
* Test whether the supplied character should be formatted literally
* or as a character entity.
*/
public boolean asEntity(char ch);
}
--__--__--
_______________________________________________
To control your jdom-interest membership:
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
End of jdom-interest Digest
More information about the jdom-interest
mailing list