Done.
I did the package rename (again) and now trying to get the stuff to
commit. Had some SSH problems before, we'll see if I can finally manage
to commit today ;-)
arkin
> I thought "org.apache.xml.serialize" was the way to go, right?
>
> --
> Stefano Mazzocchi One must still have chaos
Assaf Arkin wrote:
>
> > So, do we have an agreement on these "XML serializing" classes? I think
> > so.
> >
> > And I think Assaf can go ahead and drop them in. Anyone against this?
>
> Is that org.apache.xerces.serialize or org.apache.xml.serialize?
I thought "org.apache.xml.serialize" was the
> So, do we have an agreement on these "XML serializing" classes? I think
> so.
>
> And I think Assaf can go ahead and drop them in. Anyone against this?
Is that org.apache.xerces.serialize or org.apache.xml.serialize?
arkin
>
> --
> Stefano Mazzocchi One must still have chaos in oneself
Eduardo Pelegri-Llopart wrote:
>
> In my experience with these technologies,
>
> - Marshalling is used to describe taking the object(s) and making it
> ready for passing it as a parameter in some invocation.
>
> - Serialization is taking the object(s) and linearizing it for storage
> (or transmi
In my experience with these technologies,
- Marshalling is used to describe taking the object(s) and making it
ready for passing it as a parameter in some invocation.
- Serialization is taking the object(s) and linearizing it for storage
(or transmission) so it can be recovered later.
These two
>Even though serializing is a general term aptly descibing what is
happening, I
>think the overload with Java-specific serialization is bound to confuse
>people.
Only those who don't realize that "serialize" is a design pattern, not a
specific implementation. And I'm afraid my reaction is that th
Tom Palmer wrote:
>
> > When we talk about serializing the DOM, what are we talking about now? You
> > will always have to qualify this with "er Java Serialization" or "no.. the
> > xerces serialization package/mechanism."
> >
> As I mentioned before when we all sent emails with our
> different op
+1 on org.apache.xerces.serialize.
- Rajiv
Tom Palmer wrote:
[Charset iso-8859-1 unsupported, filtering to ASCII...]
> > org.apache.xerces.serialize
> >
> > or
> >
> > org.apache.serialize
> >
> Should be "org.apache.xerces.serialize" or "org.apache.xml.serialize",
> but it seems like most peo
> When we talk about serializing the DOM, what are we talking about now? You
> will always have to qualify this with "er Java Serialization" or "no.. the
> xerces serialization package/mechanism."
>
As I mentioned before when we all sent emails with our
different opinions, you could call it:
D
Even though serializing is a general term aptly descibing what is happening, I
think the overload with Java-specific serialization is bound to confuse
people.
When we talk about serializing the DOM, what are we talking about now? You
will always have to qualify this with "er Java Serialization" o
Keith Visco <[EMAIL PROTECTED]> wrote:
> +1 for org.apache.xml.serialize;
Agreed... +1
Pier
+1
- Original Message -
From: Scott Boag/CAM/Lotus
To: <[EMAIL PROTECTED]>
Sent: Thursday, November 18, 1999 12:25 PM
Subject: Re: C++ printers [was Re: [Proposal] Printer package]
>
> > Please one last vote:
>
> +1 org.apache.xml.serialize
&g
> Please one last vote:
+1 org.apache.xml.serialize
(Assaf meant to say org.apache.xml.serialize and not org.apache.serialize).
(votes that effect more than xerces should be put on the general list and
not the xerces-dev list.)
-scott
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
> 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 it never gets stuck
to any code in th
I've renamed everything Serialize/Serializer, fixed some bugs, added the
SAX2 support, and had some testing done using Cocoon, so I'm all ready
to commit.
Please one last vote:
org.apache.xerces.serialize
or
org.apache.serialize
arkin
Scott Boag/CAM/Lotus wrote:
>
> The intention is to end
TED]
e.com>cc: (bcc: Scott Boag/CAM/Lotus)
Sent by: Subject: Re: C++ printers [was
Re: [Proposal] Printer package]
[EMAIL PRO
Scott Boag/CAM/Lotus wrote:
>
> +1 to org.apache.xerces.serialize.
>
> I chatted with Noah Mendelsohn, who helped design the Java Serializable and
> Externalizable interfaces. His opinion is that the Serializable interface
> in Java is an example of the the generic technique of serialization. T
[EMAIL PROTECTED] wrote:
>
> >No, please, Cocoon uses the idea of "producers" and "generators" would
> >just increase the confusion.
>
> Let's face it: almost any good term will already be used by someone...
Good point.
> If you want something that's completely accurate, rather ugly, but becau
OK, sounds good. As long as we end up with one set of printers,
rather than two (which I think would be too confusing).
Mike
Assaf Arkin wrote:
>
> Mike Pogue wrote:
> >
> > Very cool. Thanks!
> >
> > So, let me make sure I understand. Are there TWO printers of this type
> > (one from Arkin, o
Mike Pogue wrote:
>
> Very cool. Thanks!
>
> So, let me make sure I understand. Are there TWO printers of this type
> (one from Arkin, one already in Xalan somewhere)? Does Arkin's replace
> the Xalan one, or does it do something different than the Xalan one, or
> am I just totally confused her
Very cool. Thanks!
So, let me make sure I understand. Are there TWO printers of this type
(one from Arkin, one already in Xalan somewhere)? Does Arkin's replace
the Xalan one, or does it do something different than the Xalan one, or
am I just totally confused here?
Thanks,
Mike
Keith Visco wro
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
t;[EMAIL PROTECTED]To: [EMAIL PROTECTED]
e.com>cc: (bcc: Scott Boag/CAM/Lotus)
Sent by: Subject: Re: [Propo
>No, please, Cocoon uses the idea of "producers" and "generators" would
>just increase the confusion.
Let's face it: almost any good term will already be used by someone...
If you want something that's completely accurate, rather ugly, but because
of its ugliness unlikely to be a conflict, there'
e.com>cc: (bcc: Scott Boag/CAM/Lotus)
> Sent by: Subject: Re: [Proposal] Printer
> package
> [EMAIL PROTECTED]
> office.com
>
>
> 11/15/99 07:13
>
(bcc: Scott Boag/CAM/Lotus)
Sent by: Subject: Re: [Proposal] Printer
package
[EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
>
> >I dislike serialization because there's a lot of demand for what Java
> >referes to as serialization,
>
> OK. Then I suggest "generate" as an antonym for "parse".
No, please, Cocoon uses the idea of "producers" and "generators" would
just increase the confusion.
A
ble.
>
> -scott
>
>
> Assaf Arkin
> <[EMAIL PROTECTED]To: [EMAIL PROTECTED]
> e.com>cc: (bcc: Scott Boag/CAM/Lotus)
> Sent by: Subject:
Mike Pogue wrote:
>
> Hey, Arkin...can we get a C++ version, too, so that the two
> Xerces parsers stay together? I'd expect that the Java and
> C++ Xerces parsers would want to serialize and canonicalize
> identically.
The Java code can be migrated into C++, but I'll have to decline this
one, I
with serialize...
>
> Linearize/linearizer might work.
>
> -scott
>
>
> "Tom Palmer"
> <[EMAIL PROTECTED]To: <[EMAIL PROTECTED]>
> pia.com> cc: (bcc: Scott Boag/CAM/Lotus)
>
e.com>cc: (bcc: Scott Boag/CAM/Lotus)
Sent by: Subject: Re: [Proposal] Printer
package
[EMAIL PROTECTED]
m> cc: (bcc: Scott Boag/CAM/Lotus)
Subject: Re: [Proposal] Printer
package
Hey, Arkin...can we get a C++ version, too, so that the two
Xerces parsers stay together? I'd expect that the Java and
C++ Xerces parsers would want to serialize and canonicalize
identically.
Mike
Assaf Arkin wrote:
>
> OK. Package name changes to org.apache.xerces.serialize
>
> arkin
>
> T
OK. Package name changes to org.apache.xerces.serialize
arkin
Tom Palmer wrote:
>
> > people confuse because Java semantics are a bit different and more
> > common.
> >
> The trick is having to cope with two groups using the same
> word in slightly different ways, and any name picked that is
>
> people confuse because Java semantics are a bit different and more
> common.
>
The trick is having to cope with two groups using the same
word in slightly different ways, and any name picked that is
nice for Java may end up being bad for another language.
It would be good to use the terms that
I don't have a problem granting commit access to folks who are
going to work on the code.
- Original Message -
From: Scott Boag/CAM/Lotus
To: <[EMAIL PROTECTED]>
Cc:
Sent: Monday, November 15, 1999 12:59 PM
Subject: Re: [Proposal] Printer package
> Download a se
Yep.
This is a future thing.
- Original Message -
From: Assaf Arkin <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, November 15, 1999 2:18 PM
Subject: Re: [Proposal] Printer package
> According to the W3C, additional requirements are to deal with
> nam
I will not object to having the package named serialize if it makes
sense from a DOM/XSLT semantic, I just hold that it's going to get
people confuse because Java semantics are a bit different and more
common.
arkin
Assaf Arkin wrote:
>
> [EMAIL PROTECTED] wrote:
> >
> > I missed most of this d
>I dislike serialization because there's a lot of demand for what Java
>referes to as serialization,
OK. Then I suggest "generate" as an antonym for "parse".
__
Joe Kesselman / IBM Research
[EMAIL PROTECTED] wrote:
>
> I missed most of this discussion, but: If by "print" you mean "render as
> XML syntax", the DOM group refers to that operation as "serialize".
>
> (Serialization is another one of the issues on the table for DOM Level 3.)
I do mean render as some syntax, could be XML
At 01:15 PM 11/15/99 -0800, [EMAIL PROTECTED] wrote:
>In the future:
>
>http://www.w3.org/TR/xml-c14n
>
>I'm sure Tim or James can tell us more about whether this is ready for use
>yet.
>I haven't had time to read it yet.
If you read this any time before today, re-fetch it; someone at W3C had
post
for use
> yet.
> I haven't had time to read it yet.
>
> For now, Clark's definition works for me.
>
> Ted
> - Original Message -
> From: Assaf Arkin <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Monday, November 15, 1999 12:37 P
[Proposal] Printer
package
04:09 PM
in
> <[EMAIL PROTECTED]To: [EMAIL PROTECTED]
> e.com>cc: xalan-dev@xml.apache.org,
> (bcc: Scott Boag/CAM/Lotus)
> Sent by: Subject: Re: [Proposal] Printer
> package
>
I missed most of this discussion, but: If by "print" you mean "render as
XML syntax", the DOM group refers to that operation as "serialize".
(Serialization is another one of the issues on the table for DOM Level 3.)
__
Joe Kesselman / IBM Research
k's definition works for me.
Ted
- Original Message -
From: Assaf Arkin <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, November 15, 1999 12:37 PM
Subject: Re: [Proposal] Printer package
> > Also, I'd like to see a printer that can generate "cano
Scott Boag/CAM/Lotus)
Subject: Re: [Proposal] Printer
package
11
<[EMAIL PROTECTED]To: [EMAIL PROTECTED]
e.com>cc: xalan-dev@xml.apache.org,
(bcc: Scott Boag/CAM/Lotus)
Sent by: Subj
IL PROTECTED]
> ia.com> To: <[EMAIL PROTECTED]>
> cc: (bcc: Scott Boag/CAM/Lotus)
> 11/15/99 Subject: Re: [Proposal] Printer
> package
> 02:
Mike Pogue wrote:
>
> I think we have one of these around somewhere, that we've been
> using for testing. It's more than just whitespace formatting.
> I believe it sorts attributes as well, if I remember correctly.
Yep, you're absolutely right. So we've got:
* No formatting
* No CDATA
* Attri
(bcc: Scott Boag/CAM/Lotus)
11/15/99 Subject: Re: [Proposal] Printer
package
02:20 PM
I think we have one of these around somewhere, that we've been
using for testing. It's more than just whitespace formatting.
I believe it sorts attributes as well, if I remember correctly.
Mike
Assaf Arkin wrote:
>
> > Also, I'd like to see a printer that can generate "canonical" XML. This i
> Also, I'd like to see a printer that can generate "canonical" XML. This is
> especially handy for testing purposes.
Keith just explained to me that canonical XML is a minimal XML document,
i.e. one without CDATA sections, indentation or any extra formatting. In
the SAX case any document you pri
> I don't think this is a good assumption. In my view we are making
> components, which should be standalone. For instance, Xalan is useable
> without any parser at all, though this tends to be an unlikely scenario.
> It is certainly designed not to have tight coupling with Xerces.
I took that i
- Original Message -
From: Assaf Arkin <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, November 15, 1999 10:52 AM
Subject: Re: [Proposal] Printer package
Okay, I just took a quick look through the code:
In general I like what I see. This is much better than
We need to include this on the Xalan dev list, or move it up to the general
list.
> There's need for the printers to be available for XML parser users. The
> printers in Xalan required a separate download, are very well hidden
> (took me two attempts to locate them because I knew they were there!
ROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, November 12, 1999 5:41 PM
Subject: [Proposal] Printer package
> I would like to introduce a printer package implementing XML/HTML/XHTML
> printing with DOM and SAX interfaces.
>
> The ability to print XML documents in these thr
> In general, I like the structure of the .printer code more than what is
> currently in Xalan, and think it would be a great starting base.
Scott, thank you.
The exisiting code base deals with CData (setCDataElements) and raw
characters (setUnescapedElements). There are also event handles for
co
First, I don't really like the term 'Printer' for this functionality. I
would rather see something like 'serializer', so, for the moment, I'll use
that term in this note.
> 1) put printers inside the parser (as Assaf proposes)
> 2) put printers inside the processor (as it is today)
> 3) put prin
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:
>
> Alternatives are:
>
> 1) put printers inside the parser (as Assaf proposes)
> 2) put printers inside the processor (as it is today)
> 3) put printers inside FOP
> 3) create a new project
>
+1 for option 1 from me. To parse and print a XML document is a commonly used
combination. If I need to imp
Assaf Arkin wrote:
>
> I would like to introduce a printer package implementing XML/HTML/XHTML
> printing with DOM and SAX interfaces.
>
> The ability to print XML documents in these three generic formats should
> be the reponsibility of the parser package. The DOMWriter and SAXWriter
> in the sa
> I would like to introduce a printer package implementing XML/HTML/XHTML
> printing with DOM and SAX interfaces.
>
I think these would be a good addition to Xerces.
I like that the printer simply implements a DocumentHandler
interface. This is the way I feel it should be done.
- Tom Palmer
I would like to introduce a printer package implementing XML/HTML/XHTML
printing with DOM and SAX interfaces.
The ability to print XML documents in these three generic formats should
be the reponsibility of the parser package. The DOMWriter and SAXWriter
in the samples directory do not implement s
65 matches
Mail list logo
