× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Thanks Scott! I know where the worms are now, I can start digging.
learning to fishing will have to come at a later time.

On Tue, Feb 26, 2013 at 3:59 PM, Scott Klement
<midrange-l@xxxxxxxxxxxxxxxx>wrote:

I would not use %TRIM or have a hard-coded blank in your expressions.
You should echo exactly what's in the XML, and not assume that you
always want to remove/add blanks at particular portions of the code.

Another problem with your code (now that I see what it looks like) is
that it doesn't handle XML tags nested inside other XML tags. It seems
to assume that the start of any XML tag is the beginning of your data,
and the end of any tag is the end of your data. If you hit another tag
in the middle, it'll go haywire.

If you look at my example (in the link you provided) you'll see that I
implement a stack of XML tag names/values, so when one is nested inside
the others, it doesn't screw anything up.

-SK


On 2/26/2013 2:46 PM, rick baird wrote:
Thanks Scott - just your mentioning XML_PREDEF_REF got me what I needed.
And short answer to your question, yes, he was replacing the value
instead
of adding to it. He also wasn't even looking at XML_PREDEF_REF.

I just put some code to allow a break point when the event equaled that
and
fished around for what the variables looked like, and I have it working
_ok_ now - probably not the most elegant code, but I don't have time to
become an XML expert today, I've got other deadlines whizzing by my head.

but if I may, a simple thumbs up or down to the following very incomplete
psuedocode would be great -

when event = XML_START_ELEMENT
clear receiver variable
when event = XML_CHARS;
receiver = %trim(receiver) + ' ' + %subst(chars:1:stringlen)
when event = XML_PREDEF_REF
receiver = %trim(receiver) + ' ' + %substr(chars:1:1)
when event = XML_END_ELEMENT
stored value = %trim(receiver)

Thanks again for your help!

On Tue, Feb 26, 2013 at 2:54 PM, Scott Klement
<midrange-l@xxxxxxxxxxxxxxxx>wrote:

Hi Rick,

I don't know what the code looks like, but... given your symptom of
"...losing all the characters before and including that string...", I'm
guessing that the original guy did something like this:

ParsedData = Value;

Instead of:

ParsedData += Value;

i.e. he's wiping out any existing data in the string rather than adding
it on to the end.

-SK



On 2/26/2013 1:45 PM, rick baird wrote:
Scott, well, the guy who wrote it (not available) appears to be
attempting
to handle those events, but not correctly I guess.

I suppose I need to crack the books.

On Tue, Feb 26, 2013 at 2:32 PM, Scott Klement
<midrange-l@xxxxxxxxxxxxxxxx>wrote:

Sounds to me like you are handling the XML_CHARS event, but not
handling
the XML_UCS2_REF, XML_PREDEF_REF or XML_UNKNOWN_REF events.

If you were handling those events properly, the parser wouldn't
"freak"
(which I doubt it's doing, anyway) and you wouldn't have to do any
special "manipulating" of the data.

Remember, refs like &amp; are a normal part of XML. They shouldn't
require any special processing on your part!


On 2/26/2013 1:14 PM, rick baird wrote:
hey all,

I'm working on a program to parse XML using the "new" XML-SAX
handlers
and
have a question.

I did not write the program, so I'm kind of working backwards here -
I
don't fully understand the XML operations - trying to learn as I go,
but
I'm sure others must have run across this problem and can give me an
idea
of where to look to fix it.

the program works just fine 99.9% of the time, but one of the data
elements
comes through with replacement characters for an ampersand '&' - i.e.
&amp;

the parser sees this and freaks, losing all the characters before and
including that string, making the value whatever is after the
ampersand.
basically, it interprets this:

the value is supposed to be: 'TRAVELERS CASUALTY & SURETY CO. OF
AMERICA'
which comes in from the 3rd party (after ebcdic translation) as:
<value xsi:type="soapenc:string">TRAVELERS CASUALTY &amp; SURETY
CO.
OF
AMERICA</value>
when the parser is done with it, it looks like this:
' SURETY CO. OF AMERICA'

I can manipulate the characters any way I want, but is '&' the only
character that gets treated this way? are there other &xxxx;
replacement
variables for other characters?

I feel like I'm fishing without a worm here. I don't want to read
every
XML link on infocenter or elsewhere searching for something that
should
be
simple.

thanks in advance!

Rick

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.