I'm using autoconf and automake to make manage the makefiles
for my project which uses xerces. And basically what I want
to do is to have ./configure for my project to complain if it
can't find the Xerces-C libraries and headers. If Xerces-C is
installed would like ./configure to figure
I'm a Windows developer, so what I'm about to ask may be
dumb. Is there any possibility that your library includes
debugging symbols?
Yes, that's his problem. Debug builds of C++ on Solaris are enormous. Well,
even Linux is, but Solaris is really big.
-- Scott
There was a change made to the Base64.cpp source around Xerces 2.2 that has
created some real problems handling base64 encoded objects, in particular
because of linefeeds. I'm not sure what's legal and what's not, but I
thought I'd mention it, because if it's *allowable* to permit extra linefeed
What PeiYong mentioned about the Schema production really maybe should be
the job of the Base64 validator, to validate and enforce the production
for 0 or 1.
That's my personal opinion too, but OTOH, Xerces' docs don't say that I
should be using the Base64 class myself either, so they don't
This discussion piqued my interest (what did Scott mean when
he said the whitespace issues are a real mess?), so I did a
little research. For those who know as little as I, here's
what I found.
Note that the context for my comment is mostly digital signatures. The major
problem there
I am building an application named 'contrast'. This
application uses one of my library 'esxml4c' that has got the
code int fullSrcCount =
std::char_traitsXMLCh::length(srcData); in one of it's cpp
file. Now my application is giving linking error on Solaris.
Thouhg it builds successfully
The other reason is that there are other platforms we could issue binaries
for but for which it's not obvious that the need is there. To whit:
- Linux on 64-bit AMD (gcc 3.2.2)
- Linux on 32-bit PPC (gcc 3.2)
- Linux on 64-bit Z/OS (gcc 3.2)
I'd be interested in the Z/OS build, assuming
How are you linking your module, and are there any other modules being
loaded that use C++ that are built with an older libstdc++? The latter will
cause the behavior you're seeing.
mod_php is a common culprit, since it uses C++.
-- Scott
I'm compiling the module with g++ and installing with 'apxs -i'
I would skip the apxs stuff until you have it working. But as long as you're
linking with g++, my guess is the crash is from two versions of libstdc++
getting loaded into Apache by different modules.
-- Scott
That is not correct.
XML Schema Part 2: Datatypes defines the ID type in accordance to the ID
type in the DTDs. The question still is, does Xerces recognize Schema
defined IDs? It does claim support for the given specification.
It does, but only if you validate the instance, or use DOM3 calls
It seems like what you're saying is the only way to parse a
buffer is to write it to a file. Am I correct in this assumption?
No, C++ streams are not file I/O, they're I/O period. Using a stream lets
you parse either one with the same input abstraction.
I use it to create object classes that
Why not use std::basic_stringXMLCh instead, if your compiler's standard
library has templated string classes?
Because newer versions of g++ have strictly followed the C++ standard such
that this is illegal. It is not possible unless you also provide the
complete char_traits support for
Has anyone got an implementation of char_traits for
std::basic_stringXMLCh they would be willing to share?
The impression I got from those gcc threads was that it was an absolutely
enormous amount of complex work. Maybe I misunderstood what they were
saying, but I read it to mean it
That's a loaded question, but the one I've got in mind is that it looks as
though 2.5 (and pretty much any other version) doesn't permit arbitrary XML
attributes to show up on an element declared as anyType.
This is incorrect behavior, as far as I understand it.
The interesting (and really
I think everybody has a different scheme for their EntityResolver, but a
slightly more direct question...any plans to implement catalog support like
the Java version has?
-- Scott
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For
The only way I managed to trap (schema) validation errors while parsing
using DOMBuilder was to install my own DOMErrorHandler.
*/ Is this the correct way to do this? Is there any other way?
That's how I've been doing it.
*/ How does the 'XercesValidationErrorAsFatal' feature affect this?
While it's no guarantee, referencing specific bug numbers that are
show-stoppers for you will certainly help increase the likelihood of
them getting fixed. Patches, of course, help even more ;)
I'm sure, but since somebody else already pointed to one and got deafening
silence, I had sort of
Well, there is a difference, at least philosophically, between bugs and
deliberate non-conformance.
There's a similarity when the solution becomes hacking schemas to get
things to work. That way lies madness, same as this.
I'm not a committer on the project, but I suspect it's just an issue
Yes, resources are a major issue. What people should realize as well is
that we can't just go and check a patch in. We have to ensure its OK
with regards to the appropriate standard. As everyone knows, the schema
specs are not the most readable documents in the world :), so schema
bugs
This was done intentionally. On no other platform were both debug and
release binaries both issued, so it wasn't clear why this was being done
on Windows. No functionality is lost.
As David just noted, this is a problem for at least some of us. Is there any
chance of reposting the zip file
I've been running into problems with the way data type validation of
base64Binary is done forever, but this is hitting critical now. ;-(
If I'm understanding correctly, the 2.6.0 changes now require that datatype
normalization be on (I note the default is off) in order to get very typical
base64
But you are right, Xerces internally uses
UTF-16 strings, and wchar_t isn't a cross-platform storage for
UTF-16. The point is that platforms that know this is true (like Windows)
would like to see XMLCh==wchar_t, even if they can just cast them to be
the desired type.
I agree. The big
So is there a silver bullet other then type casting to fix this issue ?
If you need portability, the only silver buller is one to the head to avoid
the obnoxious transcoding all over your code. ;-)
Otherwise, I don't know why for Windows they haven't just typedef'd it to
wchar_t, but I suspect
Technically speaking, it is legal C++, but it's a bit more involved than
this. You also have to define type traits for XMLCh and then
deal with the fact that your XMLCh strings won't work with char or
wchar_t strings, can't be printed via cout or wcout, etc.
Right, I was glossing over
We asked this last time this conversation went round. No one replied.
I recall the topic, figured it was time to ask again. ;-)
We would add it if anyone wanted to contribute.
If and when I ever manage to get it written and working, I'll certainly
contribute it.
-- Scott
Yes, this flag shall not affect content validity (in this case, the
base64 data), and this behavior is to be changed.
Thank you, if this gets fixed, I owe you a beverage of your choice!
However, I noticed that in the DOM tree, the content
remains unnormlized irregardless of the flag
The current behavior needs to change so that the flag has an effect on
DOM content only (more precisely, element content only. Attribute
normalization is always done).
Sorry if I'm being obtuse, but this is fairly critical for my library, so
I'm trying to be clear...
As far as I know, the
In order to be consistent with XercesJ, and actually that is what
XercesJ does now, is to expose the normalized/unnormalized value in DOM
based on the DOM L3's normalization_data flag, while always get internal
representation normalized and in your case, the base64 data
containing line
The new downloadable has the debug version now, please verify at
http://www.apache.org/dist/xml/xerces-c/binaries/WinNT_msvc60/,
thanks.
Yes, thanks. This helps the others affected more than me, I had to build a
special 2.6 distribution to fix that base64 problem and the xml:lang bug
until
Since I haven't heard anything from anyone on the email below, I was
wondering if anyone would have an issue with me submitting the
following change:
+1 from me, I lost a day to this missing code when I couldn't figure out
what the heck was happening.
-- Scott
I feel we really should move to the latest version of the spec, even if
we don't fully implement it. Its difficult for new users, users who are
using both c + j and it makes the project seem like not a lot is
happening - even though that is not true.
It definitely looks that way from the
In the last version of Xerces-C, there was fix for the DOM
normalization problem. When the feature is set to false,
you'll get back the non schema normalized value. Is this
still a problem for you?
That particular approach is not ideal (and it's a fairly old fix, not
recent), but more
That's the fix that I'm talking about. The DOM will store the
non schema normalized value (when validation is on and the
dom normalization feature is off).
I understand that. But the Base64 datatype validator has a new flag in 2.6
that causes a strict validation against the DOM-stored
normalized value. There's a fix after 2.6 that changed the
Sorry, when you said last version, I assumed you meant either 2.5 or 2.6,
but not unreleased cvs. ;-)
What you describe is indeed the fix I expected.
-- Scott
-
To
I'm willing to take a first-pass at a new build infrastructure and
re-factoring. Following that, it's going to require testing and
(perhaps) re-porting of various platformas/architectures/compilers to
the new system. But, as I tried to explain above, this task should be
much simpler (or
3.b. Mac re-port/test
James
3.c. Windows re-port/test
3.d. Linux re-port/test (may survive with basic posix...)
?
I'll certainly sign up to test these, at least in my applications, as well
as Solaris.
(5) Add a libcurl based netaccessor?
Has anybody else tried to build these w/gcc4?
Yeah, I did an RPM build of my patched 2.6.1 tree and had to hack on a
couple of tests for Fedora Core 3.
Patch below.
-- Scott
--- xerces-c-src_2_6_0/tests/XSValueTest/XSValueTest.cpp.orig 2005-01-17
22:06:58.992517204 -0500
+++
Would you have anymore insight? (even if it was speculation).
When I ran it just to evaluate it, it was generating a set of C++ code that
interfaced with code they supplied as well as Xerces and I found the whole
thing inordinately convoluted.
But then, I think all data binding solutions are
I guess that this is my worry. If it created source code that could
seamlessly instantiate a DOM object that could be serialized, I would be
happier to go down this route, but if it is convoluted
What I think is convoluted isn't necessarily for others, I'm just expressing
my opinion based
Because it uses the SAX Parser and therefore can only handle
statements?
But this doesn't compromise the validation or schema compliance, does
it?
We mean you can't pass a DOM in and ask is this schema-valid?. You have to
parse the actual raw XML (with SAX or DOM). Schema validity has
[
http://nagoya.apache.org/jira/browse/XERCESC-1309?page=comments#action_56737 ]
Scott Cantor commented on XERCESC-1309:
---
I have to agree with the previous comment, schemaLocation within a document is
a hack, not something that should override
41 matches
Mail list logo
