Also, this dom issue has been around forever, it may have gotten
better with 5.5. I never submitted, cuz it was an issue that was old
as dirt. You thought new xerces lib solved it, but apparently it
didn't completely. It has been just common practice/knowledge, that
the witango dom is buggy parsing xml. This is where Witango policy of
nut discussing bugs is detriment. We don't know if they are just
being ignored, or you are attempting to resolve.
We send in bug reports, and it doesn't even send us a response you
got it. It goes into the worm hole.
As an example. With RealBasic, ( and many other companies) there is a
bug tracking database. When you submit a bug, you are required to
search first to see if it has been reported. If it has, you can add
comments. If not, you can report, and include sample code to
reproduce. Within a few days, an email comes from RB, saying they
either reproduced your bug, or can't reproduce it. And the bug is
statused accordingly. If RB attempts to resolve it, they put in the
bug base "updated to xerces lib version whatever, should resolve" and
the person that submitted the bug, gets an automated email that the
status changed. So I can check if the bug is actually resolved.
With witango, you get NONE of that. You don't respond, or even admit
there is a bug, until it is a HUGE issue. Take the !CST bug for
example. It took you forever to even respond it was an actual bug.
While we were all floundering trying to find work arounds and such.
And I don't think you would have even have done that if I didn't make
a big stink.
This is very annoying, especially when you may know a workaround that
we don't know, and you sit on it. And I know that has happened before.
These are your choices, and that is fine, but these things are at the
core of why I made the decision to move to another platform. And I
use many platforms for development. I would have to rate witango the
worst out of all of them for dealing with these issues,
documentation, and support. And I am including MS in my list of
platforms.
--
Robert Garcia
President - BigHead Technology
VP Application Development - eventpix.com
13653 West Park Dr
Magalia, Ca 95954
ph: 530.645.4040 x222 fax: 530.645.4040
[EMAIL PROTECTED] - [EMAIL PROTECTED]
http://bighead.net/ - http://eventpix.com/
On Apr 26, 2006, at 6:35 PM, John McGowan wrote:
Actually I was the one who very recently ran into an issue with XML
with namespaces coming from a 3rd party that did not seem to be
handled properly by Witango and xerces. I'll see If I can
reproduce the problem again, and send a specific code example. It
became a moot point for me because I decided to just use some xslt
to remove all the namespace references to make subsequent xslt
stylesheets a bit easier to read and write.
It's possible I was doing something wrong, but I could swear that I
ended up installing the latest version of xerces and ran a command
manually outside of Witango and the xsl transform worked just
fine. Which made me assume there was a problem with Witango (or
one of it's 3rd party libraries)
/John
Robert Garcia wrote:
Most of the examples, were from people who emailed me, to use my
javaxmlcleaner to strip namespaces before parsing in witango. I
will try to find a specific example, but I know there were a few
on the list. They would not parse in witango dom, but java xml
parsed them fine, and my RB xml classes also did.
As you know, I try to send you what you need each time I find a
bug myself, whether or not you respond to me. But the examples I
saw that did this, were forwarded from others. But I think I found
one myself not to long ago. I will look for it.
--
Robert Garcia
President - BigHead Technology
VP Application Development - eventpix.com
13653 West Park Dr
Magalia, Ca 95954
ph: 530.645.4040 x222 fax: 530.645.4040
[EMAIL PROTECTED] - [EMAIL PROTECTED]
http://bighead.net/ - http://eventpix.com/
On Apr 26, 2006, at 6:11 PM, Phil Wade wrote:
Then it would also be true to say that the Xerces library does
not always like namespaces as we simply pass the string to the
Xerces library and get a pointer to a DOM back.
Robert please send me your xml code that does not work and we can
then investigate the issue.
Phil
On 27/04/2006, at 10:51 AM, Robert Garcia wrote:
Thats true, but sometimes, the dom blows up just trying to parse
xml with namespaces, so you can't even use xpath, without
stripping namespace before loading in witango as a dom.
So, I think it would true to say the Witango DOM does not always
like namespaces.
--
Robert Garcia
President - BigHead Technology
VP Application Development - eventpix.com
13653 West Park Dr
Magalia, Ca 95954
ph: 530.645.4040 x222 fax: 530.645.4040
[EMAIL PROTECTED] - [EMAIL PROTECTED]
http://bighead.net/ - http://eventpix.com/
On Apr 26, 2006, at 5:20 PM, Phil Wade wrote:
Actually Ben the DOM and XPath implementations are the Xerces
library from the Apache project. Last time I looked it
implemented namespaces quite well. All you need to do is learn
and understand how to write xpath expressions correctly. It is
a little more complex than XPointer. Namespace example below.
<@ASSIGN request$testDOM "<@DOM VALUE='<?xml version="1.0"
encoding="utf-8"?>
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<soap:Body>
<LogonResponse xmlns="http://www.munge.com/WebService/
ABAService">
<LogonResult>c8c799bb-3640-46f0-a0a3-b7105b5b646a</
LogonResult>
</LogonResponse>
</soap:Body>
</soap:Envelope>'>">
<@ELEMENTVALUE request$testDOM xpath="//*[local-name()
='LogonResult' and namespace-uri()='http://www.munge.com/
WebService/ABAService']" encoding="html">
<@VAR request$testDOM xpath="//*[local-name()='LogonResult' and
namespace-uri()='http://www.munge.com/WebService/ABAService']"
encoding="html">
Regards
Phil
On 27/04/2006, at 5:06 AM, Ben Johansen wrote:
It has been my experience that Witango DOM doen't like name
spaces (ie.
Soapenv:Envelope). Now Witango implements a pretty well know
DOM engine so
im not quite sure why this is. It could be the :
I have had to strip the name spaces prior to DOM'ing the
results from @URL.
This could be a simple Search and Replace of the : to _ or
just simply
change the : to a "" taking "Soapenv:Envelope" to "
SoapenvEnvelope "
Try removing the : and using the new name created.
Ben
-----Original Message-----
From: Dave Machin [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 26, 2006 8:30 AM
To: [email protected]
Subject: Re: Witango-Talk: Parsing DOM Response for element by
name
Neither of those work either...
Should I strip out certain parts of the results first?
----- Original Message -----
From: "Ben Johansen" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Tuesday, April 25, 2006 4:25 PM
Subject: RE: Witango-Talk: Parsing DOM Response for element by
name
Looks like XPATH has an issue with name spaces.
Have you tried:
<@elementvalue object=local$packageDOM
XPATH="/soapenv:Envelope/soapenv:Body/
AddPartnerMessageResponse/Timestamp">
or
<@elementvalue object=local$packageDOM XPATH="/
Envelope/soapenv/AddPartnerMessageResponse/Timestamp">
To force xpath to that level
Ben
-----Original Message-----
From: Dave Machin [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 25, 2006 3:12 PM
To: [email protected]
Subject: Re: Witango-Talk: Parsing DOM Response for element
by name
I'm stumped on this, can anyone see what I'm doing wrong?
I make a URL call and receive XML results. I'm trying to use
XPATH as
described below, but get no results.
The XML returned looks like this:
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<AddPartnerMessageResponse
xmlns="urn:ebay:apis:eBLBaseComponents">
<Timestamp>2006-04-25T21:37:53.484Z</Timestamp>
<Ack>Success</Ack>
<Version>461</Version>
<Build>e461_core_Unified_2718252_R1</Build>
<MessageID>2702</MessageID>
<MessageID>2703</MessageID>
</AddPartnerMessageResponse>
</soapenv:Body>
</soapenv:Envelope>
This command:
<@elementvalue object=local$packageDOM
XPOINTER="root().child(1).child(1).child(1)">
Returns 2006-04-25T22:10:32.234Z
But
<@elementvalue object=local$packageDOM XPATH="//Timestamp">
Doesn't return anything
Any ideas?
----- Original Message -----
From: "John McGowan" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Wednesday, April 05, 2006 11:35 AM
Subject: Re: Witango-Talk: Parsing DOM Response for element
by name
Dave,
XPATH="//Timestamp"
would do the trick.
XPath is a lot nicer to use than XPointer.
This of course assumes that you're using a version of
Witango that
supports XPath. If not, it's time to upgrade.
You may run into issues with namespaces. It might be easier
for you to
clean out all namespace references before traversing the DOM.
/John
Dave Machin wrote:
I'm trying to parse a DOM reponse from a web service. I'm
looking to
find a
particular element in the reponse. I know the name of the
element I
need,
but I won't always know it's position in the response.
For example, I receive the following response:
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<GeteBayOfficialTimeResponse
xmlns="urn:ebay:apis:eBLBaseComponents">
<Timestamp>2006-04-05T18:18:00.547Z</Timestamp>
<Ack>Success</Ack>
<Version>461</Version>
<Build>e461_core_Unified_2718252_R1</Build>
</GeteBayOfficialTimeResponse>
</soapenv:Body>
</soapenv:Envelope>
And I need the <timestamp> element. I can access it by
doing this:
<@elementvalue object="local$packageDOM"
element="root().child(1).child(1).child(1)">
But I'd like to be able to reference <timestamp> instead of
having to
know
the root/child relationships.
Is there an easy way to do this?
Dave Machin
_________________________________________________________________
_______
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/
maillist.taf
_______________________________________________________________
_________
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/
maillist.taf
________________________________________________________________
________
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/
maillist.taf
________________________________________________________________
________
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/
maillist.taf
_________________________________________________________________
_______
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/
maillist.taf
_________________________________________________________________
_______
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/
maillist.taf
__________________________________________________________________
______
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/
maillist.taf
___________________________________________________________________
_____
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
____________________________________________________________________
____
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
_____________________________________________________________________
___
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
______________________________________________________________________
__
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
________________________________________________________________________
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf