RE: Xerces-C Panic attack

I previously wrote: >>I assume this should be >> >>const char* const XML4C_DLLName = "xerces-c_1_0" XML4C_DLLVersionStr; Apparently it should have been const char* const XML4C_DLLName = "xerces-c" XML4C_DLLVersionStr;

Re: Request for Vote: Dom Package Change

[EMAIL PROTECTED] wrote: > >Errr, how is that possible? The way things normally work is, parser > >reads XML resource, loads it into data structure, offers DOM API to it. > > Most of the DOM could be constructed using public DOM APIs, if you pass a > Document into the parser. There may be a few

Re: Request for Vote: Dom Package Change

> > Again, due to statement#1, there is no real reason to move the generic DOM > above the xerces package, but there are motivations to separate it into its > own package. > > -Ralf Correction: One reason to move a generic DOM out above Xerces is so that you don't need the xerces jar simply to

RE: cloning DOMString's on assignment in Xerces-C

David_N_Bertoni@lotus.com [mailto:[EMAIL PROTECTED] Wrote: >>The meta issue here is that I think this is a very confusing implementation >>for C++ programmers -- most would think that a DOMString is more like the >>typical C++ string class (std::string, for example), rather than a Java >>StringBuf

Re: Request for Vote: Dom Package Change

Tim Bray wrote: > At 12:14 PM 11/18/99 -0700, Tom Palmer wrote: > >Still, what if someone wanted to use one organization's parser > >and another's DOM implementation? These should be kept > >independent if at all possible. > > Errr, how is that possible? The way things normally work is, parser

Re: [Proposal] Printer package

> 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

Re: [Proposal] Printer package

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

Re: Request for Vote: Dom Package Change

1) I agree that DOM clients should use the generic org.w3c.dom interfaces. In this way the client code is portable. No need to move the generic DOM just for clients who *use* it. 2) Any additional xerces DOM functionality which we want to expose to clients, and support as value-add/convenience s

Re: C++ printers [was Re: [Proposal] Printer package]

Keith Visco <[EMAIL PROTECTED]> wrote: > +1 for org.apache.xml.serialize; Agreed... +1 Pier

Xerces-C Panic attack

I ran into a problem using the very first xerces source drop on Win32. It may be fixed now and indicates that I should get familiar with CVS et al, but if someone who is more intimate with the tools could check on this, I'd appreciate it. In \src\util\Compilers\VCPPDefs.hpp const char* const XML

Re: cloning DOMString's on assignment in Xerces-C

This is a result of how DOMString was implemented. Think of it more like Java's StringBuffer class. For example, this code might surprise you: void foobar(const DOMString& theString) { DOMString foo(theString); foo += "bar"; } void foobarClone(const DOMString& theString) { DOMStri

Re: Standardizing a C++ DOM [was Re: Request for Vote: Dom Package Change

> XML in C++ has been lacking a language binding for a long, time, > and (I believe) W3C has no intention of providing one. I'd say "no current plan" rather than "no intention". I think the DOM WG's position has been that we'd like to see more standardized language bindings, but we'd like to see

Re: Request for Vote: Dom Package Change

"Rajiv Mordani [CONTRACTOR]" wrote: > Also in reply to Andy about moving to org.apache.xml - > xml.apache.org is an umbrella for a lot of xml related stuff in > Apache. There is cocoon. fop etc. So in a sense it can be > considered sort of a small org in itself. You always use I understand the

Re: Request for Vote: Dom Package Change

The first public draft should be available any day. It was handed to web engineering and will be posted in our web site any day. We will be sure to send mail announcing it when it shows. - eduard/o ps: for JCP geeks, this is JSR-5. The JCP process is described at http://java.sun.com/jcp

Re: Standardizing a C++ DOM [was Re: Request for Vote: Dom Package Change

> I think it would be nice to define, as light as possible, the set of purely > virtual class that all C++ DOM implementions should implement. > Second the motion. Dynamic method binding can be performed in short time these days, if I understand correctly. XML in C++ has been lacking a language

Re: Request for Vote: Dom Package Change

> The parser and DOM implementation are necessarily somewhat in bed, unless > we want to require DOM implementations to use SAX to build it. Do e? -T. > I think that would be a great way to build a DOM from parsed data, personally. Instant reusability of parts. I haven't actually gotten into Xe

cloning DOMString's on assignment in Xerces-C

I've noticed in some places string assignments first clone the right hand side and in other places they don't. I don't know if this is intentional, an artifact of the derivation from XML4J, or just an unnecessary bit of overhead. If someone could enlighten me, I'd appreciate it. For example: Th

Re: Standardizing a C++ DOM [was Re: Request for Vote: Dom Package Change

I think we would be doing a great service if we could come up with a good C++ binding for DOM. Things to think out: Strings - You can't define a DOM without using strings. Java has a native Unicode support it their string class. In C++ we need to roll our own. What would an abstract DOM use?

Re: Request for Vote: Dom Package Change

>Errr, how is that possible? The way things normally work is, parser >reads XML resource, loads it into data structure, offers DOM API to it. Most of the DOM could be constructed using public DOM APIs, if you pass a Document into the parser. There may be a few exceptions left, but the intent is t

Re: C++ printers [was Re: [Proposal] Printer package]

+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 > > (Assaf meant to say org.apache.xml.serializ

Re: C++ printers [was Re: [Proposal] Printer package]

> 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

cvs commit: xml-xerces/c/src/util/Transcoders/ICU ICUTransService.cpp

abagchi 99/11/18 12:16:58 Modified:c/src/util/Transcoders/ICU ICUTransService.cpp Log: Now works with ICU 1.3.1 Revision ChangesPath 1.3 +5 -1 xml-xerces/c/src/util/Transcoders/ICU/ICUTransService.cpp Index: ICUTransService.cpp ==

Re: Request for Vote: Dom Package Change

At 12:14 PM 11/18/99 -0700, Tom Palmer wrote: >Still, what if someone wanted to use one organization's parser >and another's DOM implementation? These should be kept >independent if at all possible. Errr, how is that possible? The way things normally work is, parser reads XML resource, loads it

Standardizing a C++ DOM [was Re: Request for Vote: Dom Package Change

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

Re: C++ printers [was Re: [Proposal] Printer package]

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

Re: C++ printers [was Re: [Proposal] Printer package]

> 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

Re: C++ printers [was Re: [Proposal] Printer package]

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

Re: Request for Vote: Dom Package Change

> Well if you want to be real generic refer to the interfaces in org.w3c.dom. This > way they don't have to even care about which parser is generating the DOM tree. Still, what if someone wanted to use one organization's parser and another's DOM implementation? These should be kept independent if

Re: A release version of XML4C

Yep. XML4C 2.3.1 on the IBM website has a bug, where the debug DLL's accidentally got linked in. Since source code and project files are provided, you can recompile it yourself to fix this, or you can wait until the next IBM binary release, which will fix the bug (I don't have a date for when thi

Re: C++ printers [was Re: [Proposal] Printer package]

The intention is to end up with one set of serializers/printers sooner rather than later. I might note that the arguments made for pulling the DOM out of the xerces package also apply to the serializers/printers. -scott

Re: [Proposal] Printer package

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

Re: Request for Vote: Dom Package Change

"Rajiv Mordani [CONTRACTOR]" wrote: > >> The question to resolve is whether or not people think that the > >> DOM implementation is *the* generic DOM for all of the Apache > >> XML project. If "yes", then let's move it. If "no", then we > >> need to ask if there is a generic DOM. > > Well if you

Re: [Proposal] Printer package

[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

Re: Taz overload

On Tue, 16 Nov 1999, Michael Mason wrote: > How does the Apache funding setup work? Do you have a budget, or rely on > donations, or what? http://www.apache.org/foundation/contributing.html#how-to-donate > What's Taz's spec at the moment? PII 266, 256MB ram, 22GB of disk (but only at SCSI-II

Re: Request for Vote: Dom Package Change

>Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm >X-No-Archive: yes >list-help: >list-unsubscribe: >list-post: >Delivered-To: mailing list [EMAIL PROTECTED] >User-Agent: Microsoft Outlook Express Macintosh Editio

Re: C++ printers [was Re: [Proposal] Printer package]

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

cvs commit: xml-xerces/java/src/org/apache/xerces/parsers SAXParser.java

twl 99/11/17 16:58:55 Modified:java/src/org/apache/xerces/parsers SAXParser.java Log: Move call to setSendCharDataAsCharArray to fix null document handler handling Revision ChangesPath 1.2 +3 -2 xml-xerces/java/src/org/apache/xerces/parsers/SAXParser.java

Re: C++ printers [was Re: [Proposal] Printer package]

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

Re: Request for Vote: Dom Package Change

Rajiv Mordani [CONTRACTOR] <[EMAIL PROTECTED]> wrote: > > P.S. A step aside just curious on how do you plan to use the DOM nodes in > other applications??? In some cases, I don't need to PARSE XML streams... In some cases I can just generate a memory representation of a XML document, and then pri

Re: Request for Vote: Dom Package Change

Andy Clark <[EMAIL PROTECTED]> wrote: > [...] (I would like > Xerces to move under the "org.apache.xml" package ...but that's > a whole separate argument.) Rajiv forwarded Stefano's E-Mail sent to Jakarta explaining the reasons of this. We use the naming described there since a couple of years in

Re: Request for Vote: Dom Package Change

I would vote for a change to "org.apache.xml.dom". (I would like Xerces to move under the "org.apache.xml" package ...but that's a whole separate argument.) The question to resolve is whether or not people think that the DOM implementation is *the* generic DOM for all of the Apache XML project.