I disagree. By having separate interfaces for strings for DOM and SAX, we
run into all sorts of performance hits. For example, in Xalan, we have a
DOM that we want to serialize. We have classes like FormatterToHTML and
FormatterToXML, all derived from SAX's DocumentHandler. Methods in the
Docu
Did you set the XERCESCROOT variable?
In your case it needs to be set as :
export XERCESCROOT =/home/grace/xerces-c1_0-linux
Arundhati
Java Technology Center, Silicon Valley -- XML Technology Group
Lotus Notes:Arundhati Bhowmick/Cupertino/IBM Internet:
[EMAIL PROTECTED]
1-408-777-5
I don't believe that its reasonable to strictly say that we will put out a
16 bit character. That's following a spec, that wasn't design for this
language, to the point that its counterproductive. As long as the code
points stored are Unicode code points, the size of the character is best
set to
Of course, you do what you need to do for the parser's internal
representation. But at the API level, where people deal with DOM and SAX,
then we have more constraints. The W3C DOM recommendation mandates that
DOMString's are strings in UTF-16 encodings. So, strictly speaking, the
parser's DOM
Actually, XMLCh cannot be always a 16 bit unsigned. It needs to float to
wchar_t, which is what is required to allow it to go straight to the wide
char APIs on the local platform. This might mean that its 32 bits in size.
This has not been done so far, due to a failure on my part to 'splain what
Oops. Sorry our packaging scripts are still not quite there yet.
We have just refreshed the win32 binary archive. Hopefully, we got
the packaging right this time.
rahul
As I see it, there are two reasons why you might need to transcode.
First, you might need it to access some particular algorithm you need. You
have some nice tokenizer class, or a regular expression class that takes
char *. Instead of rewriting the class to take XMLCh*, you transcode,
process a
At 11:55 AM 12/20/99 -0700, [EMAIL PROTECTED] wrote:
>I would like to go on the record as saying that I'm very much against this
>proposal, nothing personal.
I'm with Mr. Roddey. At this point in history, doing extra work or adding
extra complexity in order to empower people to dodge internation
I would like to go on the record as saying that I'm very much against this
proposal, nothing personal.
I believe that the simplicity and maintainability of the current
architecture is more important. The work to make the parser core
conditionally do Unicode or ASCII is more than I'm willing to
On Monday, December 13, 1999 at 8:17 PM [EMAIL PROTECTED] wrote:
<<>>
I'd be very keen to see an option to allow XMLCh to be equated to char. We
currently have minimal interest in supporting anything other than ASCII.
Storing non-ASCII characters using Java-style NUL-free UTF8 would be a
simple w
Hi,
I have downloaded the "xerces-c_1_0_0-win32.zip" from the site
"http://xml.apache.org/dist/";. This version of the parser does not have
the ".c" files for template based classes like "NameIdPool", declared in
"NameIdPool.hpp" in the "xerces-c_1_0_0-win32\include\util " directory.
I have che
Hi
I download the xerces-c for Linux. I did the runConfigure -plinux -cgcc
-xg++. Everything is fine for this. Then I go into SAXCount directory
and run make. It gives the error of ": No rule to make target
`/home/grace/xerces-c1_0-linux/samples/SAXCount/SAXCount.cpp', needed by
`/home/grace/xe
12 matches
Mail list logo
