. In
XML4C mode, the script will build both ICU and Xerces from scratch. You
shouldn't build ICU separately.
Andy Heninger
IBM, Cupertino, CA
[EMAIL PROTECTED]
- Original Message -
From: Jack Marr [EMAIL PROTECTED]
To: ICU Mailing List [EMAIL PROTECTED]
Sent: Tuesday, July 03, 2001 10:29 AM
DLL
Andy Heninger
IBM, Cupertino, CA
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
implementation, so you might want to ask about getting her latest files.
Andy Heninger
IBM, Cupertino, CA
[EMAIL PROTECTED]
- Original Message -
From: James Berry [EMAIL PROTECTED]
To: Xerces C Dev [EMAIL PROTECTED]
Cc: Andy Heninger [EMAIL PROTECTED]
Sent: Wednesday, May 23, 2001 11:15
discussion on the topic going on over there;
follow the links above if you are interested. In the API proposal, UChar
is a 16 bit utf-16 encoded character, and thus would be completely interoperable
with XMLCh.
Andy HeningerIBM, Cupertino, CA[EMAIL PROTECTED]
- Original Message -
From: &q
or fast :-) Working the native Unicode format would
probably always have significant advantages when the bulk of data gets
big.
-- Dean Roddey Software Geek
Extraordinaire Portal, Inc [EMAIL PROTECTED]
-Original Message-From: Andy Heninger
[mailto:[EMAIL
convert from char * in an encoding
that depends on the current locale.
wchar_t seems more and more like it is best avoided altogether if
portability is of any concern at all.
Andy Heninger
IBM, Cupertino, CA
[EMAIL PROTECTED
.
Andy Heninger
IBM, Cupertino, CA
[EMAIL PROTECTED]
- Original Message -
From: Mark A Russell [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, May 01, 2001 12:00 PM
Subject: RE: XMLCh wchar_t conversion on multiple platforms
So am I correct then in assuming that I will need
Did you rebuild build xerces-c with ICU? The pre-built
binaries
do not use ICU, even if it is avialable on your
system.
ICU does support euc-kr, and xerces built with ICU should
recognize
euc-kr encoded documents with no problem.
IBM XML4C is xerces-c + ICU. Binaries are available
from
Curt,
Your code looks fine to me, and is a nice enhancement. I think that it
should go in.
The existing loop was last touched by Dean (version 1.6), and before that
by me (version 1.5), and before that was Dean's original code. None of
the earlier versions are as tight as yours.
Andy
prioritize the serializer (DOMWriter) ahead of the DOMBuilder
for xerces-c, because we have an alternative API for parsing, but
only the DOMPrint sample program for serialization.
Andy Heninger
IBM, Cupertino, CA
[EMAIL PROTECTED]
-
To u
Is there any transcode support for for fareast multibyte charset
Yes. Build Xerces to use IBM's ICU Unicode based libraries, and it'll
support just about everything.
See the docs for instructions on how to do it.
Andy Heninger
IBM XML Technology Group, Cupertino, CA
[EMAIL PROTECTED]
documented, and it hasn't been really exercised,
since there aren't any translations yet.
Do you have a set of translated messages that you want to build message
catalogs for, or were you asking about the availability of pre-translated
messages?
Andy Heninger
IBM XML Technology Group, Cupertino, CA
[EMAIL
I've confirmed that this is a bug. It's a new one -
I haven't seen it before.
The error would be correct if there had been an external
DTD but that is not the case here.
Andy Heninger
IBM XML Technology Group, Cupertino, CA
[EMAIL PROTECTED]
From: Scott R Houck [EMAIL PROTECTED]
Here
character as it appears when encoded as UTF-8.
Pretty silly, especially since we already have an encoding declaration to
tell us what the encoding is. But it seems that Microsoft is generating
utf-8 encoded XML with a BOM, and we need to be able to swallow it.
Andy Heninger
IBM XML Technology
There are no updates to Xerces-C 1.2.0a planned for the near
future. I hope that is will hold as the stable build for
at least a little while.
(New stuff, including significant performance improvements,
continues to go into CVS, and is reflected in the nightly
builds)
Andy Heninger
IBM XML
that includes enough information to
do the job and is easy for you to generate is fine.
And, a big thank you for doing the port!
Regards,
Andy Heninger
IBM XML Technology Group, Cupertino, CA
[EMAIL PROTECTED]
experiences and any required changes back to xerces-c-dev,
so that they can be folded back into the distribution.
Thanks,
Andy Heninger
IBM XML Technology Group, Cupertino, CA
[EMAIL PROTECTED]
- Original Message -
From: Leston Drake [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, June
You are right; there is a problem with the XMLCh * flavor of
this function.
Also, the documentation is not clear,but the spaces are
removed from both
ends of the string (like in Java).
Thanks for pointing out the problem,
Andy HeningerIBM XML Technology Group,
Cupertino, CA[EMAIL
I'm glad to hear that you got Xerces-c 1.1to build
OK.
It's worth moving forward to the latest code, which has many
bug fixes,
including the one you found here. You can pick it up
either
directly from CVS, or from one of the packaged nightly
builds.
The current code is about to become
I agree that making the project more friendly to those who
want static libraries is a good idea. This is a question/request that
keeps coming up.
For MSVC, a place to start might be to add a project
configuration to the existing project files, which would make it easy to build a
static lib
This code should work as is with Xerces 1.1 or newer. Other than the
createDocument() call, it should work with 1.0 as well.
(CreateDocument here is from DOM level 2. Xerces 1.0 had an older,
non-standard form of createDocument.)
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL
The text of an element is contained in text
nodes that are children of the element node. It's always a little awkward
to get it out.
Elements can have any number of children,
so you may want to generalize your code a bit. Even if there are no
nested elements, comments and entity reference
This change is now in the source cvs.
-- Andy
- Original Message -
From: Steve Dickson [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, March 30, 2000 3:11 PM
Subject: re: ElementImpl::setAttribute()
Attn: Andy Heninger
Below is the modified source for ElementImpl
Things to try to narrow this problem down -
o Do the prebuilt versions of DOMPrint and SAXPrint work on
your system, running with the prebuilt xerces DLL and the
personal.xml sample file?
o Will the prebuilt xerces + samples parse your s02.xml file?
o Will your build of xerces +
+1
Could I please have some +1's?
not, ...
This is different from just calling Initialize multiple times, which
does
NOT cause leaks.
-- Andy
- Original Message -
From: Michael Mason [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, March 28, 2000 1:10 AM
Subject: Re: memory leaks
Andy Heninger wrote:
Be aware
Be aware that there will be leaks if you repeatedly dynamically load and
unload the xerces-c library. The initialization happens over each time.
This is different from just calling Initialize multiple times, which does
cause leaks.
This problem will get fixed eventually.
-- Andy
Michael
Check that you have the latest version of the file DOM_Node.hpp.
class DOMParser is declared to be a friend of DOM_Node, which should prevent
these errors.
Adding a public getImpl function to DOM_Node is not something that I want to
do, because it would imply that accessing the impl classes
Hi Alex,
You are correct. Xerces will leak if the DLL is dynamically loaded,
unloaded, and loaded again. As Dean notes in his earlier reply, he has
added a termination method and a hook by which this kind of storage can be
recovered.
An example of use of the new mechanism for registering an
The method you are looking for is Document.importNode().
-- Andy
- Original Message -
From: Martin Duerig [EMAIL PROTECTED]
Sorry for asking novice questions: What is the best strategy to deep copy
a
node from one document to another one?
The new API for document creation in DOM level 2 is not quite as succinct as
the old static createDocument() method from the Xerces-c DOM level 1
implementation, but it's not quite as bad as all that.
Here's some sample code, taken from the CreateDOMDocument sample included
with Xerces 1.1,
ICU (which includes these files) is available from
http://www10.software.ibm.com/developerworks/opensource/icu/index.html
You need version 1.4.
It's also available from from the XML4C download page on the IBM
alphaworks website, which is probably where your .zip file came from.
The Xerces-c
Making new Node or Element subclasses that derive from DOM_Node or
DOM_Element is not really practical with the Xerces C++ DOM. The problem is
that the classes that would need to be subclassed are not DOM_Node or
DOM_Element, but the underlying implementation classes, NodeImpl or
ElementImpl.
There is no direct way to validate a DOM document in memory against
a DTD. Only the parser is able to validate a document, which
happens at the time the document is being read.
So what you are doing already is the probably your best option.
Adding some new facility to do what you want is on
The Node interface, as specified by the DOM, doesn't have a
'deleteChildNode' operation. It instead has a 'removeChild' operation.
The
DOM specification intentionally left memory management details to
implementors.
public Node removeChild(Node oldChild)
throws
James Pearson [mailto:[EMAIL PROTECTED] asks
I'm writing an app that uses the DOM parser in a loop - reading files as
they become available.
That is to say, I reuse the parser over and over after instantiating it
only
once. Is that OK?
I've noticed that memory usage climbs as I keep
I'm not sure what Borland Builder 5 does, but it seems that
Microsoft changed the argument types for the InterlockedCompareExchange()
function very recently, which has resulted in the same problem
being seen when used with their latest SDK files.
It smells like the same problem.
The ultimate
I'm about to commit a version of DOMString with many of the changes that
have been discussed in this thread, but not all, at least not yet.
Differences from Robert's original list (the message that started this
thread) are these:
o I did not remove the DOMString(char *) constructor. There's
Davanzo Luca [EMAIL PROTECTED] asks
If I understand correctly the documentation for xerces-c 1.0.0.d01 for
win32
systems, it is stated that there is not built-in parsing for ISO-8859-1
caracters; infact i get errors if I try to parse with a DOMParser these
characters; however in the FAQ you
I'm confused.
Here's the definition of InterlockedCompareExchange from my installation of
VC6, in file
whatever\VC98\Include\WINBASE.h
WINBASEAPI
PVOID
WINAPI
InterlockedCompareExchange (
PVOID *Destination,
PVOID Exchange,
PVOID Comperand
);
This matches the parameter types,
Try it again.
I removed the DEVENV_VCPP preprocessor variable, which was not being set
consistently anyway.
The inline assembly will now always be used when compiling with MSVC, which
should sidestep the problem of inconsistent definitions of
InterlockedCompareExchange.
But I'm still curious as
We need to think about where and how message catalog files should be located
on the Unix like platforms that are using the MsgCatalogLoader class.
Until now, the files have been located relative to the xerces-c DLL, using
the same code that we were using to find the transcoder files when using
Joe Gregorio writes,
The simple answer is to take transcode() out of DOMString.
[Take out print() and println() while you're at it.] A string
class should just be a container for char or wchar_t. Transcoding
and printing are functions to be applied to containers.
You might want to consider
+1
-- Andy
I'd like to request a vote on granting commit access for Jeff Rodriguez.
Jeff is joining the team at IBM and will be working on datatype
validation.
Could I please have some +1's?
Ted
44 matches
Mail list logo
