> In the case where the serializer instance doesn't support
> serializing that node type, it could throw an exception.
Why? I mean, how many serializers do you expect to be able to serialize
an attribute or a text node?
When will you use that functionality?
> processor. And there's nothing that
Arkin wrote:
> As for serializing Node that happens to be an Attribute, keep in mind
> that we're trying to define an API used by a lot of serializers. The
> question that should be raised is: would it be trivial for them to
> support it? Would a PDF serializer support that?
Perhaps not but you're
; XML4J Support
> IBM Cupertino
>
> >From: Boris Garbuzov <[EMAIL PROTECTED]>
> >Reply-To: [EMAIL PROTECTED]
> >To: [EMAIL PROTECTED]
> >Subject: Re: Review: Serializer API
> >Date: Tue, 21 Mar 2000 16:57:05 -0800
> >
> Yes, I agree with Andy. a
> public void serialize(Node node) throws IOException;
> method may be all we need to support all the Node objects including
> Document, Element, DocumentFragment, etc.
Except that I don't see it supporting anything except Document, Element
and DocumentFragment.
IF you
Sorry for not being available lately, we have two major releases
scheduled for the O'Reilly conference. No time to breath.
The following is scheduled for release RSN:
The serializers have been revised to include some bug fixes, performance
improvement and preliminary support for encodings. They h
I could not understand, were you just sending an endElement without a
stateElement?
(I can't check the line number right now, I have a newer copy on my
machine that hopefully fixes this bug.)
arkin
Boris Garbuzov wrote:
>
> String unexistingName = "unexistingName";
> documentHandler.end
Andy Clark wrote:
>
> First, I'd like to look at what's currently in the API and then
> discuss some points of design that I'd like to see in the
> serializers.
>
> DOMSerializer: I'm sort of surprised that there are methods to
> serialize a Document, Element, and DocumentFragment but nothing
> f
How about changing Method not to MimeType but rather to ContentType?
A construct I use *very* often in my HTML files is the following:
Which would correspond to an equivalent response line from a web
server or a header line in an email message:
Content-Type: text/html; charset="x-sjis"
The
Jeffrey Rodriguez wrote:
> I think that this idea has a lot of potential maybe using the TreeWalker
> method and allowing a way to register a filter then the
> serializer could be customized to output user selected nodes.
> A user can select and serialize a view of the DOM this way.
What do you t
Andy Clark wrote:
DOMSerializer: I'm sort of surprised that there are methods to
serialize a Document, Element, and DocumentFragment but nothing
for a generic Node. In fact, if you wanted to serialize a text
node or entity reference, you would first have to remove or
clone it into a DocumentFragmen
x this bug we need to check if state is null first.
Thanks,
Jeffrey Rodriguez
XML4J Support
IBM Cupertino
From: Boris Garbuzov <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: Review: Serializer API
Date: Tue, 2
Here's a good tutorial on how to use the serialiser:
http://metalab.unc.edu/xml/slides/sd2000west/xmlandjava/185.html
Boris Garbuzov wrote:
> Even if I misuse the API (I should not call this directly?) it should have
> failed friendlier than this:
>
String unexistingName = "unexistingName";
documentHandler.endElement (unexistingName);
Even if I misuse the API (I should not call this directly?) it should have failed friendlier than this:
java.lang.NullPointerException:
at org.apache.xml.serialize.XMLSerializer.endElement(XMLSerialize
My notice might be related to the subject. DOMSerializer serializes newly
created Element and DocumentFragment for me, but refuses the root element,
throwing
java.lang.ClassCastException: org.apache.xerces.dom.TextImpl
at org.apache.xml.serialize.XMLSerializer.serializeElement(XMLSerial
Andy Clark wrote:
>
> Method: I don't see a need for this class. If all it's doing
> is holding string constants, then I would say get rid of it
> completely. Otherwise, make it a Java "enumeration", like so:
>
>
I'm having the exact thoughts but I didn't articulate them well in my
last email.
First, I'd like to look at what's currently in the API and then
discuss some points of design that I'd like to see in the
serializers.
DOMSerializer: I'm sort of surprised that there are methods to
serialize a Document, Element, and DocumentFragment but nothing
for a generic Node. In fact, if you
Assaf Arkin wrote:
> I've attached a draft of the new serializer API, please review and
> comment.
I'm finally getting back to looking over the serializer stuff.
Unfortunately, it's getting late so I'll write up my thoughts
tomorrow and post it to the mailing list.
--
Andy Clark * IBM, JTC - Sil
The method name is a String. Method defines some common names, but not
all the names. You can have other serializers responding to other
methods, so it's just a place holder for names.
arkin
Wong Kok Wai wrote:
>
> Similar comments for setters that accept a string: should you check for both
> n
Similar comments for setters that accept a string: should you check for both
null
and zero-length string before assigning?
For setMethod method in OutputFormat, why not pass an instance of Method
instead of
String?
cheers,
Wong
Assaf Arkin wrote:
> You have some sharp eyes :-)
>
> arkin
>
> W
You have some sharp eyes :-)
arkin
Wong Kok Wai wrote:
>
> A quick comment: In QName, the localname checking is only for null. Should add
> checking for zero-length string too?
A quick comment: In QName, the localname checking is only for null. Should add
checking for zero-length string too?
Andy Clark wrote:
>
> Assaf Arkin wrote:
> > * Separates interfaces from implementation, all interfaces have been
> > placed in the package org.xml.serialize, implementation remains in
> > org.apache.xml.serialize
>
> I thought that org.xml package was owned by OASIS. Are we allowed
> to drop thi
Assaf Arkin wrote:
> * Separates interfaces from implementation, all interfaces have been
> placed in the package org.xml.serialize, implementation remains in
> org.apache.xml.serialize
I thought that org.xml package was owned by OASIS. Are we allowed
to drop things in there?
Thanks for posting t
23 matches
Mail list logo
