The first child, is not necessarily "Element1", but the text node
containing the carriage return.
Your in memory object model probably looks like this:
#document
#element: Element
#text: \n
#element: Element1
#text: gg
#text: \n
--Keith
Sangita Gupta wrote:
>
>
, or is it the SerializerFactory by
> maintaining an internal pool of serializers, in which case you have to
> call close() on the serializer.
>
> Either one will work with the current implementation, but the jury is
> still out on which method it should be. Comments are more than wel
My thoughts
When the depth of the tree drops back to 0 (ie. the root element is
finished printing) The serializer should reinitialize itself. I don't
like to rely on a call to #endDocument, though there is nothing wrong
with forcing a user to do so if necessary.
I don't think a Serializer n
David,
"David A. Lee" wrote:
>
> Thanks for the comments. I've already written my own (it wasnt difficult -
> took
> about an hour to integrate with our own IOStreaming classes)
Yes DOMPrint is easytrying to do a cross platform port of Assaf's
serializers is not as easy as it sounds with
David,
I've started porting the serializes to C++ for use with TransforMiiX,
unfortunatly they can't readily be used in Xerces since TransforMiiX and
Xerces use different DOM implementations and SAX interfaces. The W3C
stayed clear of giving C++ bindings, probably due to all the
inconsistencies
This is a good topic actually. The XSLT processor currently in the extensions
package of Mozilla was written by myself. It uses a C++ DOM written by one of
my ex-colleagues when I was working for MITRE and it uses the Expat XML parser
from James clark. Mozilla also has it's own DOM implementaion
Tom Palmer wrote:
> > org.apache.xerces.serialize
> >
> > or
> >
> > org.apache.serialize
> >
> Should be "org.apache.xerces.serialize" or "org.apache.xml.serialize",
> but it seems like most people are in favor of "xerces" or plain "xml".
>
> I think "xerces" is probably fine, though hopefully
I will create the SAX based C++ printers, which will be pretty much a straight
port from Assaf's code. Given time I might write the DOM printer that sits on
top of the SAX one, but that will come later.
--Keith
Assaf Arkin wrote:
> Mike Pogue wrote:
> >
> > Hey, Arkin...can we get a C++ versio
I like serialize myself! ;-)
Scott Boag/CAM/Lotus wrote:
> The question is, when would the usage conflict? Semantically, what the two
> are doing is the same. If you did node.writeObject, I would think the
> default output would be an XML file... or at least it ought to be. The DOM
> is an ob
Scott,
Once implemented the printers shouldn't change much, just drop them into the
distribution. The same printers can be in the distribution for both. They are
small, and
if we do a joint archive with both Xalan and Xerces they can share the same set
of
printers.
--Keith
Scott Boag/CAM/Lotu
I vote for keeping the printers with the XML parser. But since many projects
would/could make use of them I'm not against moving them to
a new project.
People shouldn't have to download an XSLT processor or FOP just to get the
printers.
--Keith
Stefano Mazzocchi wrote:
> Assaf Arkin wrote:
>
11 matches
Mail list logo
