Hi all!
I have a function that is attempting to parse an XML document in the
form of a string, the code for this function is as follows:
// Initialise variables
vl_MemBufID_str = "prodInfo";
// Create a new memory buffer input source
vl_MemBufInput_ptr = boost::shared_ptr (
Hi,
IIRC, we put some code in before last release that fixed a few other
problems in DOMWriter. This seems to have had the effect of introducing
the problem you are seeing. Do you have the pretty print feature on?
Gareth
On 5 Aug 2004, at 3:14, T MacAdam wrote:
I posted a question recently rega
Yes, I do have the pretty printing feature on...
Tom.
--- Gareth Reakes <[EMAIL PROTECTED]>
wrote:
> Hi,
>
> IIRC, we put some code in before last release that
> fixed a few other
> problems in DOMWriter. This seems to have had the
> effect of introducing
> the problem you are seeing. D
Hey,
then this is not strictly a bug. The spec says you can do pretty much
what you want. If you want to change the behavior, then take a look at
dom/impl/DOMWriterImpl.cpp around the 1350 line mark. If you feel you
can come up with the change you suggest without breaking anything else
I will
Thanks, I will try as you suggest. It will likely fix
it for my purposes. I am inclined to think it is
still a bug for others, however, for the simple reason
that the blank lines accumulate as I described.
That's the real problem to me; I wouldn't mind if the
pretty printer put a couple blank li
I found that I did not like the fact that DOMWriter puts out blank lines
in certain contexts, so I modified DOMWriterImpl.cpp to put an end to
that. I basically searched for any occurrences of printNewLine() that
was within a few lines of another occurrence and removed one of them. I
"fixed" 5 in
If you specify a grammar that allows the parser to determine whether
whitespace in element content should be preserved, tell the parser to
validate, and setIncludeIgnorableWhitespace(false), you can ensure that
ignorable whitespace is not included in your DOM.
There are caveats, however. See
http
Durmus,
You may need to compile
and link with "-mt". Build the xercesC from the latest code base
and see
if it can run on your hp-ia box.
Rgds,
PeiYong
"P.M.S.Prakash" <[EMAIL PROTECTED]>
wrote on 08/04/2004 10:25:36 AM:
> Hi Durmus,
>
> As per the release plan, I read that support on It
Hey,
On the other hand, there are at
least two people who would rather DOMWriter didn't insert blank lines.
Here's what I'd suggest: try hacking it up as I suggested. If you like
the results, file a bug, and one of us can attach a patch. Further
discussion can be part of the bug for posterity.
That patch parameterizes a behavior that I didn't want (throwing away an
all-whitespace text node). You can revert to the old behavior with
pWriter->setFeature(XMLUni::fgDOMWRTWhitespaceInElementContent, false);
Adam Heinz
Senior Software Developer
Exstream Software
-Original Messa
I understand the whitespace facet to be a directive to the parser
regarding how to deal with whitespace. If the whitespace facet is set
to "collapse", as it is in an xsd:token, then the following tag is
legal:
This is my token
The parser will read it in, collapse the whitespace, and then va
I would like to know if anyone has build Xerces-c 2.5 on IRIX 6.5 w/ MIPSpro 7.41.
Xerces 2.3 and 2.4 build just fine.
I run runConfigure like this: runConfigure -p irix -c cc -x CC
and then gmake.
I get the following errors..
CC -LANG:pch -LANG:std -O2 -DIRIX -D_REENTRANT -I/usr/local/in
I did some debugging tonight and it is as you
suspected, caused by the changes centering around
revision 1.44. Also, as Adam suggested, I could
revert to the old behavior by setting the
XMLUni::fgDOMWRTWhitespaceInElementContent feature to
false, except that Xerces will not allow me to set
that fe
13 matches
Mail list logo
