I started looking at porting Xerces-C to pocketPC [don't know what
platform you're looking at]. The biggest problem, and the reason why i
dropped the project is that Xerces-C uses exceptions a fair bit, and
exceptions aren't supported on pocketPC. YMMV
Cheers
Simon
On Fri, 17 Aug 2001 11:43:44 +
Curt,
I tried different upper case for ISO-8859-1, but this didn't work. This
gave me the idea that other aliases for internal transcoders might work.
After digging through Xerces code for a little while I found where they
declare all the aliases for internal transcoders. It looks like LATI
Hello,
I'm on SunOS 5.6, using Xerces v1.1.0 on GCC 3.0, just upgraded from version
2.95.2.
I've created a static library...
ar -r libxerces.a *.o
ranlib libxerces.a
...and linked it into my program.
At runtime, I receive a si
> This was the issue I was looking for. Currently if I try to
> include Xerces
> and Xalan headers I get a name collision in QName.hpp. If
> this rename could
> simplify the usage of BOTH Xerces and Xalan together I'm in.
The current version of Xalan has fixed this (by renaming their files)
[EMAIL PROTECTED] writes:
> Who's quoting man pages? I didn't quote man pages -- I'm describing what
> the C++ standard says.
Actually David, I believe he was referring to my man page quote.
> And of course it makes a difference -- I didn't
> saying that it doesn't. What I said was:
>
>
> > "Murphy, James" (The Original Poster) wrote:
> > I would also like to change the include file convention to use
> > quotes instead of angle brackets. In this way I wouldn't have to
> > modify my include path at all for any of my projects! Everything
> > would work relative to each file (some
I have plenty of work to do as it is and I don't have any problem with the
way #includes are currently handled in Xerces-C so I have a hard time voting
1. But on the other hand I can see the attraction for the change.
The best I can do is a vote of 0.
-- Bob Vaughn
Telestream, Inc.
http://www.
> Just a fuzzy second thought on Friday afternoon .. don't
> yell if you don't like it . :-)
I had the same thought this morning, but wasn't sure enough about it to float it. You
are a braver man than I.
The root directory could be just src/xercesc. However, you would have to replic
Who's quoting man pages? I didn't quote man pages -- I'm describing what
the C++ standard says. And of course it makes a difference -- I didn't
saying that it doesn't. What I said was:
1. The behavior of <> vs. "" is implementation-defined.
2. The use of <> to indicate "system" include
I instantiate a DOMParser object and call its parse method on the XML.
I perform an operation where I ask for a list of children on a node,
which is successful. Then, I call the DOMParser reset method, and once
again call the parse method on a new XML. I then perform an operation
to ask for a li
Tinny Ng wrote:
> So far here is what I understand from Murray's proposal:
>
> Proposed changes to be made in the Xerces-C Project
> =
> 1. Xerces-C source code: all #include insides the headers (e.g.
> DOMParser.hpp) and the source files (e.g. DOMParser
"David N Bertoni" wrote:
> Well, that's imposing something on C/C++ which is not defined by the
> standard, so I don't know whether I agree with that behavior or not. Are
I don't know what the standard says on the issue, but Stroustroup
is clear about the difference between ""'s and <>'s with #i
>> James Murphy <[EMAIL PROTECTED]> >
>> Currently if I try to include
>> Xerces and Xalan headers I get a name collision in QName.hpp.
> This had been fixed in the latest Xalan release, which is
> currently being
> uploaded to the Apache server even as I write this message...
I love you man.
Oh it makes a big difference on Windows. You quote man pages I'll quote the
MSDN!
Quoted form
---
This form instructs the preprocessor to look for include files in the same
directory of the file that contains the #include statement, and then in the
directories of whatever files that inc
> 1) Include no header in the XML file being read. This results in
> non-English characters being read in as a ? character.
I'm surprised that you didn't get an encoding exception since ISO-8859-1 code points
would rarely be legal UTF-8.
>
> 2) Including the header encoding="iso-8859-1" ?>.
Title: RE: memory leaks in Xerces-C++ 1.5.0 version
Hi Peoyong,
Thanks for quick reply. Aslo thanks for putting in the fix for the memory leak about the fHeadNode. But I still don't understand what do you means the qname has been fix in previous version. I checked version 1.4.0 and
If you need it and Xerces-C doesn't supply it... For Xalan-J, where we
can't assume that our input will always be coming from Xerces, we invented
a solution which involves two threads running in lockstep with each other.
One thread generates the SAX events, the other consumes them, and some
hands
Well, that's imposing something on C/C++ which is not defined by the
standard, so I don't know whether I agree with that behavior or not. Are
you saying that because makedeps has decided that <> means a system header
that everyone should believe that as well?
Dave
James Murphy <[EMAIL PROTECTED]> wrote:
> This was the issue I was looking for. Currently if I try to include
Xerces
> and Xalan headers I get a name collision in QName.hpp. If this rename
could
> simplify the usage of BOTH Xerces and Xalan together I'm in.
This had been fixed in the latest Xa
Siehnai, Does your document header specify the encoding? Something like:
would be expected by the xml processor if your file is in fact UTF-16
encoded.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
"Peter A. Volchek" wrote:
>
> Before reorganizing the xerces package and update the CVS, many things
> should be done:
> - Changing code
> - Building Xerces on all supported platfoms
> - Retesting Xerces on all platforms
> - Building samples on all platforms
> - Retesting/running samples on all p
Title: UTF-16, UCS-4 encodings
Hi,
I'm trying to parse (SAX parser) a document utilizing the UTF-16 encoding, but I keep getting an error.
It appears that the line in XMLReader::XMLReader()
fEncoding = XMLRecognizer::basicEncodingProbe(...)
always returns fEncoding = UTF-8, ev
"Murphy, James" <[EMAIL PROTECTED]> writes:
> While were on the subject of upsetting apple carts -
>
> I would also like to change the include file convention to use
> quotes instead of angle brackets. In this way I wouldn't have to
> modify my include path at all for any of my projects! Ever
Hello,
I am currently trying to internationalize a product that uses Xerces 1.5.1.
The code is written in C++ and it accesses Xerces through its xml4C COM
interface using DOM. I am running into some problems getting this to work
correctly in the case of Windows 95 on French and German system
My apologies! You're absolutely right: the first decision to make is whether
to make the change, not how.
Tinny included the CVS issue in the Against section of the summary, and I
think I contributed to the confusion by commenting on the version control
issue in the message in which I voted. I di
> It can be intimidating to answer a question
If you're feeling intimidated, remember that you can always say "I'm not
sure, but I _think_ the answer is..."
(Gods know I often rely on that. I've never actually gone through the
Xerces-C code. I tend to rely on "Well, the standard says this, and
Sorry, some more *nix novice questions.
If trying to get Xerces in the distributions is primarily to allow already compiled
code to run without having to provide the .so's, would an binary/runtime drop that did
not have header files resolve
the collision issue? People who wanted to rebuild app
+1 for me, I've been bitten more then once by clashing header files while
using xerces,
John-Mark
-Original Message-
From: Tinny Ng [mailto:[EMAIL PROTECTED]]
Sent: 17 August 2001 14:18
To: [EMAIL PROTECTED]
Subject: Changing include to include/xercesc - Summary and Vote
So far here is
"Arnaud Le Hors" <[EMAIL PROTECTED]> writes:
> Hold on! I think some people are answering the wrong question. The
> question is not (yet) "how do you want to implement the renaming?" But
> simply "do you want to rename the include dir?"
> Iff we decide to rename it, then we should discuss the pro
Nick,
The reported memory leak about the --qname-- had been solved in
the previous version, the actual "delete qname" is located at the
end of the function buildDFA().
The leak related to --fHeadNode-- has been verified and *your fix*
has been applied and tested against BoundsChecker
I vote +1 for the change.
Olivier Schmitt
-Original Message-
From: Tinny Ng [mailto:[EMAIL PROTECTED]]
Sent: Friday, August 17, 2001 6:18 AM
To: [EMAIL PROTECTED]
Subject: Changing include to include/xercesc - Summary and Vote
So far here is what I understand from Murray's proposal:
P
I've tried to avoid getting involved in this thread; not because I don't
have an opinion or because I can't be bothered to say it but rather because
everyone else involved has mirrored, to a greater or lesser degree, my
opinons, far more eloquently than I could (especially on a Friday
afternoon).
Hold on! I think some people are answering the wrong question. The
question is not (yet) "how do you want to implement the renaming?" But
simply "do you want to rename the include dir?"
Iff we decide to rename it, then we should discuss the pros and cons of
the different ways to implement it, and
"Jesse Pelton" <[EMAIL PROTECTED]> writes:
> One comment: as a paranoid version-control freak, I'd strongly discourage
> renaming repository directories. It's bad policy, and can make it difficult
> or impossible to reconstruct a prior release. Such reconstructions are one
> of the primary motiva
"Adams, David" <[EMAIL PROTECTED]> writes:
> I vote No,, '0'.
I assume you meant 'No' ==> -1
as opposed to 'Abstain' ==> 0
jas.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
"Tinny Ng" <[EMAIL PROTECTED]> writes:
> Good:
>
> 1. It helps addressing the name collisions between header files
> from various libraries that, unfortunately(but realistically),
> have the same names. Different products (3rd party or user
> applications) can also have e.g. o
- Original Message -
From: "Murray Cumming" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, August 17, 2001 18:08
Subject: Re: Changing include to include/xercesc - Summary and Vote
> "Gale, Gary (Factiva)" wrote:
> >
> > I vote +1 (and wish I had the time to try converting the
"Murray Cumming" <[EMAIL PROTECTED]> writes:
> "Jason E. Stewart" wrote:
> >
> > However, Xerces-C is already in the debian distro and has been for some
> > time.
>
> That's good news, and I'd be interested to know how they go about
> building the .debs. I can't believe that they tolerated Xerc
PLEASE DO NOT REPLY TO THIS MESSAGE. TO FURTHER COMMENT
ON THE STATUS OF THIS BUG PLEASE FOLLOW THE LINK BELOW
AND USE THE ON-LINE APPLICATION. REPLYING TO THIS MESSAGE
DOES NOT UPDATE THE DATABASE, AND SO YOUR COMMENT WILL
BE LOST SOMEWHERE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3155
> > Besides, why the profusion of operator == and
> operator !=? Isn't it
> > enough with one of them?
>
> There's a Standard C++ Library header that generates some operator
> overloads in terms of others, but I can't remember the name.
> Anway, it's
> almost certainly not available on
The reason Xerces behaves so "Java-like" is mainly because it implements
interfaces like SAX, which was invented in the Java world, and DOM, which
was specifically invented to be 'clean' OO (meaning no templates). AFAIK
there is no native C++ interface to XML.
> Those features are standard in all
Hello
We want to implement Xerces-C SAX Parser on an embedded system. There, we
don't have access to dlls.
Has someone already done this? I think the build instructions are targeted
to non embedded systems. Are there any difficulties to do this?
Thank you for your answer, best regards,
Bruno
---
Let's see ...
1) Existing code that uses Xerces is not affected in any way.
2) Build environment is affected as if it were a new distribution of Xerces,
which it is.
3) Making the change would benefit the project.
4) Somebody actually volunteered to make the change.
Seems like a no-brainer to me
Yes. Follow the instructions @ http://xml.apache.org/xerces-c/install.html.
Khaled
nicolas kuznik wrote:
Hi,
I'm trying to install Xerces-win32 on my machine (equipped with windows
2000).
Is it possible ? If yes, what is the procedure ?
Thanks
Best regards
Nicolas Kuznik
-
Just starting to use Xerces-C I vote +1.
I'm convinced that those who set up new Xerces-C projects in the future will
definitely appreciate a clean include directory structure.
Hans
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
"Murray Cumming" wrote:
> ... I believe that the Xerces-C mailing list has become significantly
> less responsive over the past year.
That's my impression, too, which emphasizes how much we've come to rely on a
handful of people (like Andy Heninger, Dean Roddey, Tinny Ng, Joseph
Kesselman, and Da
I don't understand the last sentance. there is potential namespace
collisions regarding headers that may be included by xerces code. So my app
code may not cause an include file collision (with some other library) but a
xerces header file could. How could the xerces developers know which header
fi
"Murray Cumming" <[EMAIL PROTECTED]> writes:
> OK, thanks for the comprehensive answer. I just wanted to make sure
> that somebody was at the wheel, because it's not always clear when
> I'm talking to someone with responsibility, and because I believe
> that the Xerces-C mailing list has become s
"Tinny Ng" <[EMAIL PROTECTED]> writes:
> I don't have the complete list of all Xerces-C committers, but FYI here
> are the committers that are ACTIVE for the past 12 months (i.e. have
> checked in code changes to CVS).
>
> Andy Heninger
> Arundahti Bhowmick
> Arhaud Le Hors
> Bill Schindler
> De
"Gale, Gary (Factiva)" wrote:
>
> I vote +1 (and wish I had the time to try converting the build to an
> automake driven environment).
I tried it. I found some difficulties with the platform-conditional
inclusion of some files and directories in the build. I was slowly
getting there when I lost
"J. J. Merelo" wrote:
>
> Murray Cumming wrote:
> >
> > "J. J. Merelo" wrote:
> > >
> > > -1
> > >
> > > > 1. It helps addressing the name collisions between header files from various
>libraries that, unfortunately(but realistically), have the same names. Different
>products (3rd party or use
This was the issue I was looking for. Currently if I try to include Xerces
and Xalan headers I get a name collision in QName.hpp. If this rename could
simplify the usage of BOTH Xerces and Xalan together I'm in.
While were on the subject of upsetting apple carts -
I would also like to chang
I vote +1 (and wish I had the time to try converting the build to an
automake driven environment).
Gary
--
Gary Gale Mail: [EMAIL PROTECTED]
UK Server Group Phone: +44 (0) 207 542 8814
Factiva, A Dow Jones & Reuters Company Web: www.factiva.
Sorry guys. When reading straight text, it is sometimes easy to interpret
the -minus- sign as a simple -dash- used to clarifiy the text. Just so we
all understand.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional comm
"Adams, David" wrote:
>
> Tinny, Peter,
> maybe I misunderstand, but you guys are saying you wish to keep the
> revision history intact, which implies NOT making the changes. Yet you are
> voting '1' which is in support of going through with the proposal to change
> the includes. Am I bac
It's time to remove [EMAIL PROTECTED] Everybody who posts to the
list gets one of these messages:
CompuServe Postmaster wrote:
>
> Receiver not found: albermann
>
> Your message could not be delivered as addressed.
>
> --- Message From Postmaster ---
>
> Subject: Addressing CompuServe Mail us
Tinny, Peter,
maybe I misunderstand, but you guys are saying you wish to keep the
revision history intact, which implies NOT making the changes. Yet you are
voting '1' which is in support of going through with the proposal to change
the includes. Am I backwards?
---
Also not sure why progressive parse is not in SAX2 I think it should
not be too difficult to add this in
How about you open a Bugzilla bugs to keep track of this request? We can
look into it after we finished the schema. Or if somebody volunteer to
provide the patch, we would be happy
"J. J. Merelo" wrote:
>
> -1
>
> > 1. It helps addressing the name collisions between header files from various
>libraries that, unfortunately(but realistically), have the same names. Different
>products (3rd party or user applications) can
> > also have e.g. or . So, why not have the
>Xe
Paul Emberson wrote:
>
> Currently xalanc and xercesc have the same file hierarchy. Surely for
> consistency you'd have to change xalan as well. It would make sense to do
> it all at the same time.
It would make sense to do it for all, but not necessarily at the same
time. Shortly afterwards,
-1
> 1. It helps addressing the name collisions between header files from various
>libraries that, unfortunately(but realistically), have the same names. Different
>products (3rd party or user applications) can
> also have e.g. or . So, why not have the Xerces
>include paths start with wh
Since I'm a lazy bastard and currently have no problems with the code except
to keep up with all the patches.
My vote is -1.
I don't need more work and I definately do not want a longer include path
(our include path for the project is almost to long for windows to handle
already).
Erik Rydgren
Currently xalanc and xercesc have the same file hierarchy. Surely for
consistency you'd have to change xalan as well. It would make sense to do
it all at the same time.
Paul
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For a
Tinny Ng wrote:
>
> I agree to. As a developer, sometimes I need to trace the revision history and
> try to understand why a certain change was in in place. Since this is an Open
> Source Project, it may be hard to find the original developer and inquire his
> rationale behind, so the revision
I agree to. As a developer, sometimes I need to trace the revision history and
try to understand why a certain change was in in place. Since this is an Open
Source Project, it may be hard to find the original developer and inquire his
rationale behind, so the revision history is very important (
Thanks to Tinny for a well-written description of the impact/benefit issues.
I agree with Chrisoffer.
I vote 1
> -Original Message-
> From: Christoffer Dam Bruun [SMTP:[EMAIL PROTECTED]]
> Sent: Friday, August 17, 2001 9:42 AM
> To: '[EMAIL PROTECTED]'
> Subject: RE: Changing incl
Tinny Ng wrote:
>
> Murray Cumming wrote:
>
> > My understanding is that if we rename src to xercesc then there will be
> > no need to have an include directory.
>
> No. In the binary distribution, we don't ship the source. Binary distribution only
>ships parts that are needed to "Run" the a
> One comment: as a paranoid version-control freak, I'd strongly discourage
> renaming repository directories. It's bad policy, and can make it
difficult
> or impossible to reconstruct a prior release. Such reconstructions are one
> of the primary motivations for having version control in the firs
Tinny Ng wrote:
>
> According to the Roles and Responsibilities outlined by Apache
> (http://xml.apache.org/roles.html), there are users, developers, and
> committers. Users are those who use the product. Developers are those
> that write the code and contribute as patches. And committers are
According to the Roles and Responsibilities outlined by Apache
(http://xml.apache.org/roles.html), there are users, developers, and
committers. Users are those who use the product. Developers are those
that write the code and contribute as patches. And committers are those
who have the write au
Murray Cumming wrote:
> My understanding is that if we rename src to xercesc then there will be
> no need to have an include directory.
No. In the binary distribution, we don't ship the source. Binary distribution only
ships parts that are needed to "Run" the applications, i.e., the headers
Tinny Ng wrote:
>
> So far here is what I understand from Murray's proposal:
>
> Proposed changes to be made in the Xerces-C Project
> =
> 1. Xerces-C source code: all #include insides the headers (e.g. DOMParser.hpp) and
>the source files (e.g. DOMParser.cp
+0. That is to say, I don't think this makes much difference to me
personally, but I can see how it would be useful to others and it seems
appropriate.
One comment: as a paranoid version-control freak, I'd strongly discourage
renaming repository directories. It's bad policy, and can make it diffi
I vote 1
I think it is prefereable that the xerces refers to xercesc/util/...
instead of util/...
/Christoffer
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
I vote No,, '0'. I've never had a problem compiling Xerces or my own apps
with the right headers. I haven't followed the discussion real closely, but
I've been engineering for quite a few years and never ran across a situation
I couldn't get around without asking a vendor to modify their source
So far here is what I understand from Murray's proposal:
Proposed changes to be made in the Xerces-C Project
=
1. Xerces-C source code: all #include insides the headers (e.g. DOMParser.hpp) and
the source files (e.g. DOMParser.cpp) will be modified with 'xerc
This question came up a few days ago... is there any clarification ?
m.v.h.
Christoffer Bruun
email: [EMAIL PROTECTED]
tlf: 89432000
---
Ed is the standard text editor.
If you use ed, you are on the path to redemption, the
so-calleds "visual" editors have been placed here by ed to tempt the
>>> Why is there bool operator== (const string& str_)const
>> Are you sure that there is? I thought that there was no use of
>> std::string in Xerces-C? In the DOMString class?
>Sorry, it should have said why _isn't_ there
Seems like this has been already addressed in responses to a prio
Murray Cumming wrote:
>
> "J. J. Merelo" wrote:
> >
> > Hi,
> > Why is there bool
> > operator== (const string& str_)const
>
> Are you sure that there is? I thought that there was no use of
> std::string in Xerces-C? In the DOMString class?
>
Sorry, it should
"J. J. Merelo" wrote:
>
> Hi,
> Why is there bool
> operator== (const string& str_)const
Are you sure that there is? I thought that there was no use of
std::string in Xerces-C? In the DOMString class?
>
> I agree that strings can be easily converted t
Hi,
Why is there bool
operator== (const string& str_)const
I agree that strings can be easily converted to char* ; but it
would make things much easier.
Besides, why the profusion of operator == and operator !=? Isn't it
enough
"J. J. Merelo" wrote:
>
> Hi,
> In this code:
> DOM_NodeList list = grand.getChildNodes(); // works
> DOM_Node param = grand.getFirstChild(); // coredumps with
> segmentation violation
>
> How come I get the child nodes as a list without a problem, but not get
> the first child? H
Hi,
In this code:
DOM_NodeList list = grand.getChildNodes(); // works
DOM_Node param = grand.getFirstChild(); // coredumps with
segmentation violation
How come I get the child nodes as a list without a problem, but not get
the first child? How can I test if the FirstChild is availa
Kavitha B S wrote:
>
> Hi,
> We have an Application which needs to be compiled on Solaris 8.
> Could u tell me if it is safe to use Xerces-c library which is Built on
> Solaris 7 and Build our Application on Solaris 8.
> Or Do we need to build xerces-c on Solaris 8 and then Build the
>
I believe that Xerces-C++ 1.5.1 fixed some memory leaks. Anyway, it is
generally a good idea to check the latest version before reporting a
bug.
> Nick Chiang wrote:
>
> Hi,
>
> I found two places may have memory leak problem.
>
> First, in src/validators/common/DFAContentModel.cpp Lin
"Arnold, Curt" wrote:
>
> > No, I have said several times that this will not require any
> > existing apps to change the way that they #include the
> > Xerces-C++ headers. Read the thread.
>
> Actually, I had read every message in the thread before posting. I had not been
>following the thread
86 matches
Mail list logo
