Probably because it has to support a wide range of compilers, some of which
may only support the "classic" syntax. One of the challenges the project
has is determining when all the compilers for which there is or has been
support are sufficiently advanced to allow usage of modern technologies.
(Us
Any idea why the xerces-c project uses "classic" iostreams all over the place instead
of the "standard" iostreams ?
I mean for eg., instead of
-Vinayak
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-ma
Hi,
a NodeIterator is meant to just iterate over a list of nodes. A
TreeWalker provides a view of the tree that you can navigate via calls
such as nextSibling(), previousSibling(), parentNode(). You are correct in
saying that with whatToShow set to the same value, the default result will
be
Actually, the 1.0 spec doesnt mention anything about case.. it is only in
the 1.2 version that they talk about "case folding"..
The discussion the meaning of "match" in section 1.2 (Terminology) of the
1.0 specification says:
- "Two strings or names being compared must be identical."
- "No case
Thanks for the response.
> Bear in mind that XML is case-sensitive - it's part of the
> specification.
Actually, the 1.0 spec doesnt mention anything about case.. it is only in the 1.2
version that they talk about "case folding"..
Yes I understand the need behind keeping xml case sensitive - t
I need to be able to iterate through the nodes in a DOM tree, and have been
looking at both DOMNodeIterator and DOMTreeWalker, and I'm somewhat
confused. Both classes seem to do very nearly the same thing.
DOMTreeWalker has additional functionality that recognizes that it has a
tree, methods deali
Bear in mind that XML is case-sensitive - it's part of the specification.
Xerces is compliant with the spec. Changing it to be case-insensitive in
some or all cases would break that compliance, so such changes do not belong
in the released code.
In other words, I imagine you'll need to make any ne
David N Bertoni/Cambridge/IBM wrote:
Hi Andrei,
(...)
You are transcoding characters to the local code page, using
XMLString::transcode() (I'm assuming that's what XML::getTextContext()
does). Unfortunately, there is no way to tell if those characters can be
represented in the local code pa