> 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 figu
> 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
ch
> 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'
> 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
> I am building an application named 'contrast'. This
> application uses one of my library 'esxml4c' that has got the
> code "int fullSrcCount =
> std::char_traits::length(srcData);" in one of it's cpp
> file. Now my application is giving linking error on Solaris.
> Thouhg it builds successful
> 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, assum
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 ca
> I've looked at MemParse and it gives you general information,
> but I want the actual node information and data. I have a
> parser that parses a file, but now I need to parse a buffer,
> i.e. a char*.
I use a stream& input source for C++, but it should generalize.
-- Scott
class
> 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 tha
> Why not use std::basic_string 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 localization
> Has anyone got an implementation of char_traits for
> std::basic_string 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 wasn't pr
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 weird)
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
> And note the second "C" in "XERCESCROOT".
Yeah, umm, any chance you guys could maybe patch the script to look for
XERCESROOT as well? I can't tell you how many people mis-type that, myself
included...
-- Scott
-
To unsubscri
> 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 th
> It's true that Microsoft's parser allows these characters, but it's
> non-standard behavior. If you really want to use XML, it's best to avoid
> relying on such non-standard behavior.
While the list is discussing the importance of adhering to standards, is
there any hope of getting a few simp
> 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 o
> 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 is
> As a suggestion for the entire mailing list, why don't we use the "vote
> for this bug" feature of Jira? At least we can have a feeling of
> what the users really think is urgent to fix.
Yep, I certainly did. Of course, I can't vote for my own. ;-)
This is exactly what I was asking, essentiall
> 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
> bug
> 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 fi
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 c
> Because std::wstring is not so standard... for instance, gcc
> 2.95 doesn't have it.
Heh, if that was the reason (as opposed to the fact that the *encoding* of
wstring isn't standard), I'd be screaming for the change. ;-)
-- Scott
-
> 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 a
> 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 d
> 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 f
> 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 li
> I think libcurl would make a great netaccessor base, at least for
> unixes and Mac OX X, where libcurl is apt to be present anyway. It
> might make sense for Windows, through we'd then has an external
> dependency to resolve.
+1. I use it extensively.
-- Scott
-
> 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
unt
> I just was annoyed at having mistyped XERCESCROOT as XERCESROOT for
> about the 100th time this week. Does this happen to others so much or
> am I just that screwy? Gotta watch those details...
Yes, I'm ashamed to say it bugs the heck out of me.
-- Scott
--
> 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 th
> 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 val
> 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
-
T
> 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 (
> > 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
> 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
+++ xerces-c-src_2_
> 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 in
> 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 base
> 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 ha
[
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
48 matches
Mail list logo
