Cache Listing Causing Invalid Pocket Query GPX file

[+PDOP's]

One of the Pocket Query files I received this morning would not load into GSAK. I believe the problem is with this cache GCYHM7 and in particular this line

[+Raine]

One of the Pocket Query files I received this morning would not load into GSAK. I believe the problem is with this cache GCYHM7 and in particular this line

 

Fixed the listing, should work fine now.

 

-Raine

[+The Leprechauns]

How about fixing all the caches that won't load in Plucker?

[+ClydeE]

I can't speak for the plucker, but I will point out that the Cache in the OP originally generated an invalid GPX file. Such a file will (or should) be rejected by any XML reader, not just GSAK.

 

The line causing the problem comes out as:

 

The container is an large old green and white round tupperware container.

 

This means the XML file is not "well formed" and does not pass validation.

 

It shouldn't matter what the user enters in the cache description, the generated GPX file should still be "well formed"

 

I would humbly suggest this be fixed at the source (the code used to actually generate the XML file, or better yet when validating user input) to prevent this in the future.

[+mertat]

How about fixing all the caches that won't load in Plucker?

Have you tried Sunrise? I finally gave up on Plucker because of the caches that won't load. Haven't had any trouble with them using Sunrise.

[robertlipe]

Invalid HTML (which will choke Plucker-like substances, including web browsers, which expect to see valid HTML) is different than invalid XML. While I'm on public record as being against both, I saw the cache in question before Raine "fixed" it and it was a case of the latter, not the former. Sunrise is more tolerant of naughty HTML, but it still requires something being able to parse XML to make that HTML from a PQ and when that XML isn't parsable, that's a problem.

 

GPSBabel, like most XML readers that conform to the W3C.org recommendations, will reject a PQ that contains illegal character entities like the cache originally did and will suggest mailing the contact address in the hopes that the provider can provide a non-broken XML file.

 

PLEASE fix this at the source. Don't require human intervention to manually "fix" such pages. The last time this problem surfaced, it was amongst my top support problems for nearly a year before Elias put it into remission.

[+benh57]

Fixed the listing, should work fine now.

-Raine

 

That is not the proper fix.

[topografix]

I'll echo Robert Lipe's request that this get some attention at the source. GeoBuddy's GPX parser will refuse to open a GPX pocket query that contains mal-formed XML. It's a support headache for me, as well.

 

Thanks Jeremy for your quick response to the last instance of this I reported.

[+PDOP's]

I'll echo Robert Lipe's request that this get some attention at the source.

Yes please me too. I reran this Pocket Query today with the same results. The cache that caused the problem GCYNM7 is not included this time so something else is causing problems. The PQ is #615498

[+The Leprechauns]

How about fixing all the caches that won't load in Plucker?

Have you tried Sunrise? I finally gave up on Plucker because of the caches that won't load. Haven't had any trouble with them using Sunrise.

I did try, based on advice from helpful people like you. I am somewhat tech-challenged and could not get Sunrise to work with my Palm and PQ's. So I gave up, and now my Palm Tungsten E is nothing more than an expensive paperweight, without PQ data to put in it. I shelled out another several hundred bucks for a laptop computer as an alternative solution. It works great, except for hiking caches where I wish I could have the cache description and hints along with me.

 

My comment was made out of frustration. I cannot tell the difference between bad HTML and bad XML. All I know is that Plucker is a recommended software tool for paperless caching, and the data which the site provides to me won't work. I would like to see such problems fixed at the source, not on a cache by cache basis.

[+PDOP's]

One of the Pocket Query files I received this morning would not load into GSAK.

This same PQ (615498) for this week won't load again. Will someone at Geocaching.com please look at this and correct the bad HTML or whatever is causing the problem.