[jdom-interest] AleXMLOutputter
tsasala at hifusion.com
tsasala at hifusion.com
Mon Jul 17 09:10:47 PDT 2000
Andrzej Bialecki wrote:
>
> On Mon, 17 Jul 2000 tsasala at hifusion.com wrote:
>
> >
> > I'm a little confused here. What's the serious problem with
> > having toString like methods on all the objects? It would output the
>
> No problem, if the toString() is recursive, that is. But in that case,
> it's not really different from getSerializedForm.
Yep ;)
>
> > basic information in a generic way, thus, keeping the API simple and
> > very useful. Additional classes can be formulated to handle a wide
> > range of tasks that toString can't (or won't). Much like the
> > proposition of of a Format class.
>
> How is that different from XMLOutputter, if we rename it to XMLFormatter?
>
It's not. Don't really know what the name will work out to.
-Tom
Received: from newstakes.com (ad202.166.12.1.magix.com.sg [202.166.12.1])
by dorothy.denveronline.net (8.9.3/8.9.3) with ESMTP id GAA28108
for <jdom-interest at jdom.org>; Mon, 17 Jul 2000 06:09:26 -0600 (MDT)
Received: from vmg-atm0 (vmg-atm0 [202.166.12.1])
by newstakes.com (8.9.3/8.9.3) with ESMTP id UAA06838
for <jdom-interest at jdom.org>; Mon, 17 Jul 2000 20:04:53 +0800 (SGT)
Date: Mon, 17 Jul 2000 20:04:53 +0800 (SGT)
From: Ching-Kuan Thum <ckthum at newstakes.com>
X-Sender: ckthum at vmg
To: jdom-interest at jdom.org
Message-ID: <Pine.GSO.4.05.10007172000330.6355-100000 at vmg>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: [jdom-interest] why "." not allowed in XML name
Sender: jdom-interest-admin at jdom.org
Errors-To: jdom-interest-admin at jdom.org
X-BeenThere: jdom-interest at jdom.org
X-Mailman-Version: 2.0beta2
Precedence: bulk
List-Id: JDOM Mailing List for General Issues and Updates <jdom-interest.jdom.org>
hi,
I've used a xml element with name "body.head" and got the
following exception when I tried to create Document object:
org.jdom.JDOMException: The name "body.head" is not legal for JDOM/XML
elements:
. is not allowed in XML names..: The name "body.head" is not legal for
JDOM/XML
elements: . is not allowed in XML names..
at org.jdom.input.SAXBuilder.build(SAXBuilder.java:231)
at org.jdom.input.SAXBuilder.build(SAXBuilder.java:323)
I have no problem with the DOM parser of xerces. Is this JDOM specific
requirement ?
Thanks in advance.
Regards,
Thum
Received: from mimer.webgiro.com ([212.209.29.5])
by dorothy.denveronline.net (8.9.3/8.9.3) with ESMTP id IAA02385
for <jdom-interest at jdom.org>; Mon, 17 Jul 2000 08:25:21 -0600 (MDT)
Received: by mimer.webgiro.com (Postfix, from userid 66)
id 088A92DC0B; Mon, 17 Jul 2000 16:30:30 +0200 (CEST)
Received: by mx.webgiro.com (Postfix, from userid 1001)
id 979937817; Mon, 17 Jul 2000 16:20:15 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
by mx.webgiro.com (Postfix) with ESMTP
id 951A910E17; Mon, 17 Jul 2000 16:20:15 +0200 (CEST)
Date: Mon, 17 Jul 2000 16:20:15 +0200 (CEST)
From: Andrzej Bialecki <abial at webgiro.com>
To: tsasala at hifusion.com
Cc: Elliotte Rusty Harold <elharo at metalab.unc.edu>, alex at jguru.com,
jdom-interest at jdom.org
Subject: Re: [jdom-interest] AleXMLOutputter
In-Reply-To: <3972F79A.9F6FDBB5 at hifusion.com>
Message-ID: <Pine.BSF.4.20.0007171615120.89707-100000 at mx.webgiro.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: jdom-interest-admin at jdom.org
Errors-To: jdom-interest-admin at jdom.org
X-BeenThere: jdom-interest at jdom.org
X-Mailman-Version: 2.0beta2
Precedence: bulk
List-Id: JDOM Mailing List for General Issues and Updates <jdom-interest.jdom.org>
On Mon, 17 Jul 2000 tsasala at hifusion.com wrote:
>
> I'm a little confused here. What's the serious problem with
> having toString like methods on all the objects? It would output the
No problem, if the toString() is recursive, that is. But in that case,
it's not really different from getSerializedForm.
> basic information in a generic way, thus, keeping the API simple and
> very useful. Additional classes can be formulated to handle a wide
> range of tasks that toString can't (or won't). Much like the
> proposition of of a Format class.
How is that different from XMLOutputter, if we rename it to XMLFormatter?
> -Tom
>
> Andrzej Bialecki wrote:
> >
> > Hello,
> >
> > On Sat, 15 Jul 2000, Elliotte Rusty Harold wrote:
> >
> > > At 7:45 AM -0700 7/14/00, Alex Chaffee wrote:
> >
> > > >I rewrote XMLOutputter to have public methods for serializing nodes
> > > >other than document. Patch is at the end of this email. I don't want
> > > >to step on Rusty's toes here, but the fact is, my code works, more or
> > > >less, so an argument could be made for checking it into the main code
> > > >base pending further developments from Rusty's camp.
> >
> > > The issue I see with these is that the API is far more complex than
> > > it needs to be. This is not sufficient to replace
> > > getSerializedForm(). Given an Element e (or a Comment c, or a
> > > Document d) calling getSerializedForm() is easy. Just
> > >
> > > String s = e.getSerializedForm();
> >
> > I've been lurking here for some time, but not too long, so I'm not sure if
> > this topic was discussed before...
> >
> > Anyway: why Elements, PIs, DocType etc.. don't extend the same basic
> > class? Or implement common interface that extends Serializable? IMHO it's
> > easier for developer to just throw whatever he has on the plate to the
> > XMLOutputter without having to know which particular method to use for
> > this particular node type. I think this would simplify API.
> >
> > The reason for this question is that in my application I have to serialize
> > parts of documents, starting from specific node (not from the root), and
> > then store split parts (adding some decoration like docType) into
> > different locations. Tt would be nice to have possibility to supply any
> > document fragment, not only the root element, to XMLOutputter and receive
> > it in serialized form.
> >
> > > The big issue is how to configure the formatting performed by
> > > XMLOutputter.getSerializedForm(). We could:
> >
> > I don't mind supplying additional object specifying dozens
> > of serialization parameters. This would buy me extra flexibility of
> > having different serialization parameters for different document
> > fragments (e.g. pretty formatting for parts likely to be read by
> > humans, condensed spaghetti for parts to be stored in the DB).
> >
> > I'd vote for OutputFormat class, if it matters :-)
Andrzej Bialecki
// <abial at webgiro.com> WebGiro AB, Sweden (http://www.webgiro.com)
// -------------------------------------------------------------------
// ------ FreeBSD: The Power to Serve. http://www.freebsd.org --------
// --- Small & Embedded FreeBSD: http://www.freebsd.org/~picobsd/ ----
More information about the jdom-interest
mailing list