Delorme users being sent wrong GPX version

[+Pax42]

I realize the folks at Groundspeak are hard at work resolving the PQ generator issues and I appreciate their efforts but I felt this needed some attention as well. Many people are being sent pocket querries in the new 1.0.1 format even though their preference is set to 1.0. It doesn't seem to be a problem for Garmin users but Delorme users using Cache Register or Topo USA 8 to load their units are having problems. CR doen't work with the 1.0.1 format and sends caches to the PN-XX as waypoints instead. PQs sent to Topo also can show up as waypoints but also show the GC# rather than the cache title. Some of us have been helping people fix this with the following steps:

 

1- go to GC.com and click on YOUR PROFILE

2- then click on Your Account Details

3- scroll to the bottom of that page to Your Preferences

4- if it is set to 1.0.1, skip to step 10

5- click on change

6- find GPX Version Preference and change it to 1.0.1

7- click on Save Changes

8- click on change again

9- if the GPX Version Preference setting now says 1.0, go back to step 6 (yes really)

10- find GPX Version Preference and change it to 1.0

11- click on Save Changes

12- re-run the PQs that have the version problem, the new PQs should be OK

 

This has been a issue since the last site update 2 weeks ago. Is there a way to do a global reset of some kind to make sure everyone is receiving what their preference says they should receive? People continue to post in the technology forum and on the Delorme forums asking for help, thinking the problem is on their end.

[+dakboy]

I realize the folks at Groundspeak are hard at work resolving the PQ generator issues and I appreciate their efforts but I felt this needed some attention as well. Many people are being sent pocket querries in the new 1.0.1 format even though their preference is set to 1.0.

I'm not convinced that this is exactly what's happening. What it looks like to me is that the default setting for PQs is 1.0.1, and if the user hasn't explicitly set their preference, that's what they get.

 

However, when you go to the Profile Preferences, if you've never set a preference before, the listbox defaults to 1.0, but that's only because there's no value there at all. It only appears that your preference is 1.0 - nothing is actually stored in the database until you do the dance you've posted here.

 

I never had a problem with PQs after that update, but I also fiddled with my preference before the update happened, for reasons I don't recall.

 

This has been a issue since the last site update 2 weeks ago. Is there a way to do a global reset of some kind to make sure everyone is receiving what their preference says they should receive? People continue to post in the technology forum and on the Delorme forums asking for help, thinking the problem is on their end.

I'm sure there's a very easy way to set everyone's preference to 1.0 if they haven't selected one for themselves, assuming the user preferences are stored in a conventional way in the database.

[+Pax42]

You make a very good point. I hadn't thought of the possibilty that the 1.0.1 attributes were never actually being sent out until the latest update even though the 1.0.1 option has been there for awhile. Since 1.0.1's introduction as a choice, all those that hadn't fiddled with their preference got sent 1.0.1 but since it was not yet different than 1.0, no one noticed a problem. Does that make since? I'm not a software guy. It's just all 1s and zeros to me .

[+pppingme]

People continue to post in the technology forum and on the Delorme forums asking for help, thinking the problem is on their end.

This really IS a delorme problem, and they need to fix their software.

 

The gpx files are simply xml files, nothing fancy, version 1.0.1 is simply an extra tag (attributes).

 

The "problem" is that delorme can't handle an unknown tag (in this case the attributes) in the file.

 

The PROPER way to handle this is to ignore the tag, not choke on it.

 

This issue really should be raised on the delorme side for them to fix their software to politely ignore rather than choke on an unknown tag, as the rest of the world does when processing xml files.

 

Does this mean every time gs wants to include something new that they have to wait for delorme to catch up? Absolutely not. The rest of the world didn't choke on the new data, and delorme shouldn't have either.

[+dakboy]

Both parties are at fault.

 

Yes, DeLorme's software needs to be more tolerant of the XML being produced. The DeLorme Send To GPS plugin still doesn't work with Firefox 3.6 either, and it's been over a month since 3.6 was released. DeLorme has not been keeping up with updates to CR - maybe they're holding everything until May/June, when their next GPS & Topo USA releases happen, I don't know - it's getting annoying though.

 

On the flip side, Groundspeak first introduced attributes in GPX files in the fall without giving adequate warning to others. And this latest site update changed the format received by users who had not made a preference selection (if you hadn't made a selection, you used to get 1.0. Now you get 1.0.1.) I didn't see anything in the release notes about it - again, lack of communication on Groundspeak's part.

 

If you're going to have a default format given to users who haven't made a selection, make it the lowest common denominator, and don't change it after it's been in use for a few months.

[+beejay&esskay]

From the beginning there was a problem changing Version. I wanted 1.0.1. I thought I made the correct change. My PQs came through as 1.0. I went back and changed it again and all was well.

 

I would have just written this off as user error, but a number of other users reported the same thing. (And we see steps 5-9 in the OP are to handle this error.)

 

It's not a Delorme issue. It's a G.S. issue if you cannot make the change to version in a straight-forward manner.

[+Pax42]

This really IS a delorme problem, and they need to fix their software.

 

The gpx files are simply xml files, nothing fancy, version 1.0.1 is simply an extra tag (attributes).

 

The "problem" is that delorme can't handle an unknown tag (in this case the attributes) in the file.

 

The PROPER way to handle this is to ignore the tag, not choke on it.

 

This issue really should be raised on the delorme side for them to fix their software to politely ignore rather than choke on an unknown tag, as the rest of the world does when processing xml files.

 

Does this mean every time gs wants to include something new that they have to wait for delorme to catch up? Absolutely not. The rest of the world didn't choke on the new data, and delorme shouldn't have either.

While I agree Delorme's software should better handle this (which I believe they are working on), I still think it's reasonable to expect the PQ I receive to be the format that is shown in my preferences or at least be provided communication before a change takes place, that I will need to go into my profile and manually set that preference no matter what it currently shows.

[+pppingme]

On the flip side, Groundspeak first introduced attributes in GPX files in the fall without giving adequate warning to others.

Since the change was a simple addition of a new tag, no one needed advance notice (I'm NOT saying gs shouldn't have put out notice, they very much should have, BUT it shouldn't have mattered). I would agree with you if a tag were being removed or changed, since some program could be dependent on that tag, but that's not the case here.

 

No application that is reading an xml file should break just because there is a new/unexpected tag, period.

 

So, notice or not (and yes, they should have notified), the app shouldn't have broken, and it did.

 

I also disagree with gs having made a work around to accommodate a broken app, those are development hours that would have been much better spent elsewhere. GS's response should have been to ignore the complaints after clarifying that the .gpx is indeed good clean xml data.

[+Pax42]

If I order a steak off a menu and brought my own fork to eat it with, but get sent soup instead which the fork won't work too well with, is it my fault for bringing a fork or the restaraunts fault for delivering the wrong order?

[+Avernar]

If I order a steak off a menu and brought my own fork to eat it with, but get sent soup instead which the fork won't work too well with, is it my fault for bringing a fork or the restaraunts fault for delivering the wrong order?

Actually it's more like this. You bring a fork and order a steak as you said, but the waiter brings you your steak AND a bowl of soup. What do you do?

 

1) Ignore the steak because you don't have a spoon for the soup?

 

2) Eat the steak and ignore the soup?

 

Delorme is doing #1, everyone else is doing #2.

[+dakboy]

If I order a steak off a menu and brought my own fork to eat it with, but get sent soup instead which the fork won't work too well with, is it my fault for bringing a fork or the restaraunts fault for delivering the wrong order?

Actually it's more like this. You bring a fork and order a steak as you said, but the waiter brings you your steak AND a bowl of soup. What do you do?

 

1) Ignore the steak because you don't have a spoon for the soup?

 

2) Eat the steak and ignore the soup?

 

Delorme is doing #1, everyone else is doing #2.

There was at least one other person (fizzymagic, IIRC) who was caught off-guard by the PQ format change last fall. We can discuss proper XML handling till we're all blue in the face, but the fact remains that you should not change your API without telling people!

 

But everyone is dogpiling on DeLorme here over the XML and ignoring the real issue which Groundspeak can address - for users who have not selected a GPX format, Groundspeak changed the default version they get from 1.0 to 1.0.1 without notice, and without any indication in the user's preferences. In your preferences, it still shows 1.0 if you haven't made a selection!

[+Avernar]

There was at least one other person (fizzymagic, IIRC) who was caught off-guard by the PQ format change last fall. We can discuss proper XML handling till we're all blue in the face, but the fact remains that you should not change your API without telling people!

I agree that all API changes need to be announce because you can't expect all the programs out there to be properly written. People need time to test to see if they made some bad assumptions in there code.

 

There are two things that happened in last fall's PQ format change.

 

1) The "Unknown Cache" type was rename to "Mystery Cache" if I remember correctly. This is what broke a lot of programs. This should have just been handled as a new cache type by the program. These program also probably broke when Wherigo Cache was added and the programmers never learned a lesson.

 

2) The <Groundspeak:attributes> section was added. There is no acceptable excuse by the programmers why this wasn't just ignored. None. "But Groundspeak should have told us" is just trying to shift the blame. Admit you made a mistake, fix your code, and get on with it.

 

But everyone is dogpiling on DeLorme here over the XML and ignoring the real issue which Groundspeak can address - for users who have not selected a GPX format, Groundspeak changed the default version they get from 1.0 to 1.0.1 without notice, and without any indication in the user's preferences. In your preferences, it still shows 1.0 if you haven't made a selection!

We're not ignoring the "real" issue. There are two issues here, neither one is less "real" than the other. I agree 100% that the GPX selection option has several problems and needs to be fixed.

[+Pax42]

Honestly, my original post was not meant to pass blame on anyone. It was meant to try and get some help for a lot of folks out there who don't understand why caches aren't loading properly to their PNs. All they know is that it worked one day and didn't the next. It seems Groundspeak is in the best postion to provide relief the fastest. Delorme is working on Topo 9 and updates to cache register which may resolve some of those issues you are all talking about with the xml handling but the release of those products are still likely several months away. A simple communication from Groundspeak to all users to go into their profile and select the GPX version they wish to receive and save it may be enough to resolve this for now.

[+Avernar]

Honestly, my original post was not meant to pass blame on anyone.

I was referring to the programmers of the broken applications when I said they were trying to pass the blame.

 

It's great that you found the cause of the problem and provided a workaround.

[+Pax42]

Honestly, my original post was not meant to pass blame on anyone.

I was referring to the programmers of the broken applications when I said they were trying to pass the blame.

 

It's great that you found the cause of the problem and provided a workaround.

Although I've been helping pass the fix around, I can't take credit for coming up with it. Some folks more knowledgeable of xml than me figured it out over on the delorme forums. The specific steps came from Robert Shelley. I wouldn't have even thought to open the GPX file in a text editor to see what was going on.

[+Avernar]

I wouldn't have even thought to open the GPX file in a text editor to see what was going on.

At least you're not doing what's in your tag line and ARE learning from others!

 

If you're curious and haven't tried already, temporarily switch to 1.0.1 and grab a GPX from a cache page (that has attributes) then switch back to 1.0 and download the same GPX. Take a look at them side by side in a text editor to see what's been added.

[+tozainamboku]

If I order a steak off a menu and brought my own fork to eat it with, but get sent soup instead which the fork won't work too well with, is it my fault for bringing a fork or the restaraunts fault for delivering the wrong order?

Please try to only use ice cream analogies. I don't understand steaks and forks.

 

The ice cream store use to sell only ice cream in cones. Recently they added the option to get a dish of ice cream. A customer who had always gotten cones came in and asked for a scoop of vanilla. It was served to him in a dish. He tried to eat the dish and couldn't. Whose fault was it?

 

1. The ice cream shop for giving a customer, who up to now had always gotten a cone, the ice cream in a dish and not telling him that this was a new option?

 

2. The customer for trying to eat the dish?

 

---

Thinking about it some more. It's more like the ice cream use to come in a dish but now it comes in a cone. The customer who wanted just the dish of ice cream should just eat the ice cream and leave the cone. Of course, had he never expected a cone he might have trouble putting it down on the table so he could use his spoon to eat the ice cream.

Edited March 11, 2010 by tozainamboku

[+Avernar]

Please try to only use ice cream analogies. I don't understand steaks and forks.

Ice cream it is!

 

Customer orders a cone with two scoops of chocolate each day for the past several years so the owner just gives him the usual. One day a new hire at the ice cream store serves the customer and gives him three scoop: chocolate, vanilla and chocolate. What should the customer do?

 

1) Not eat anything and throw the whole cone in the garbage?

 

2) Eat the first scoop of chocolate, throw out the vanilla scoop, and then eat the other scoop of chocolate. Then either say nothing or mention that there was an extra scoop of vanilla in there.

 

See why my example is different that yours? The customer always got two chocolate scoops in the past, the customer STILL got two scoops of chocolate. The only difference is that there was something extra in there one day. In #2 the customer was smart enough to just skip over the vanilla scoop.

 

Same thing in XML. The XML parsing library will say "Here's a section with the tag Groundspeak:attributes, want it?" All the app has to do is say "No" and the library will skip that section of the file automagically. It really is that simple, both in English and in Code.

[+dakboy]

Please try to only use ice cream analogies. I don't understand steaks and forks.

Ice cream it is!

 

Customer orders a cone with two scoops of chocolate each day for the past several years so the owner just gives him the usual. One day a new hire at the ice cream store serves the customer and gives him three scoop: chocolate, vanilla and chocolate. What should the customer do?

 

1) Not eat anything and throw the whole cone in the garbage?

 

2) Eat the first scoop of chocolate, throw out the vanilla scoop, and then eat the other scoop of chocolate. Then either say nothing or mention that there was an extra scoop of vanilla in there.

 

See why my example is different that yours? The customer always got two chocolate scoops in the past, the customer STILL got two scoops of chocolate. The only difference is that there was something extra in there one day. In #2 the customer was smart enough to just skip over the vanilla scoop.

 

Same thing in XML. The XML parsing library will say "Here's a section with the tag Groundspeak:attributes, want it?" All the app has to do is say "No" and the library will skip that section of the file automagically. It really is that simple, both in English and in Code.

It isn't that simple if the customer has a severe allergy to one of the ingredients in the vanilla ice cream and can't eat any of the cone he was given because the vanilla was sandwiched in the middle. He regularly asked for one specific item, and then one day the vendor changed what he was handing out without first checking to make sure it was OK. Customer walks up, expects to get what he's always gotten, and doesn't.

 

All this does not excuse the fact that Groundspeak is showing people that they have a 1.0 preference, but they're handing out 1.0.1. It's completely misleading and false.

[+tozainamboku]

Please try to only use ice cream analogies. I don't understand steaks and forks.

Ice cream it is!

 

Customer orders a cone with two scoops of chocolate each day for the past several years so the owner just gives him the usual. One day a new hire at the ice cream store serves the customer and gives him three scoop: chocolate, vanilla and chocolate. What should the customer do?

 

1) Not eat anything and throw the whole cone in the garbage?

 

2) Eat the first scoop of chocolate, throw out the vanilla scoop, and then eat the other scoop of chocolate. Then either say nothing or mention that there was an extra scoop of vanilla in there.

 

See why my example is different that yours? The customer always got two chocolate scoops in the past, the customer STILL got two scoops of chocolate. The only difference is that there was something extra in there one day. In #2 the customer was smart enough to just skip over the vanilla scoop.

 

Same thing in XML. The XML parsing library will say "Here's a section with the tag Groundspeak:attributes, want it?" All the app has to do is say "No" and the library will skip that section of the file automagically. It really is that simple, both in English and in Code.

Ok. Try this.

 

The customer always got a scoop of rocky road ice cream in a dish. The ice cream was chocolate with nuts and marshmallows. The ice cream store changed the recipe and added coconut to the ice cream along with the nuts and marshmallows.

 

Now if the customer has one of those fancy-shmancy XML parsing spoons, it would have separated the ice cream into the chocolate ice, nuts, marshmallows, and coconut. The customer would've eaten the parts of the ice cream he wanted and ignored the other parts. And should the recipe change and new ingredients be added, the super-dooper fancy spoon would have continued to work and separate out these ingredients as well.

 

But the customer is a small person with limited room in his pocket for fancy-shmancy spoons. So instead they used a regular old spoon that takes all the ingredients of the ice cream together. Now when a new ingredient is added the customer has to ingest the ingredients because they don't have a special spoon. Maybe this customer really doesn't like coconut. When he took in a mouthful of ice cream that has some coconut he became sick and spit the whole thing out.

 

What is really going on is an argument betweent one group of people who say "If you eat ice cream you have to use the special XML parsing spoon. That way if the ingredients change you can ignore the ones you don't like." And another group that says, "I can eat the ice cream with what ever kind of spoon I want. If you change the ingedients without telling me, I will spit out everything, but if you give me enough advance notice, I can prepare for the changes and learn to tolerate the coconut."

 

Which group is right? I would say both are. If you did use the special spoon (perhaps one can even get this spoon for free) you would cetainly be able to tolerate certain kinds of changes to the ice cream. On the other hand, it might not be reasonable to expect every one to use this special spoon. Even if you can get a spoon for free, it might not fit in your pocket or it may be difficult for you to hold. Should the ice cream shop assume everyone uses a special spoon or should they try to let customers know in advance that the ingredients in the ice cream are changing?

[+Avernar]

It isn't that simple if the customer has a severe allergy to one of the ingredients in the vanilla ice cream and can't eat any of the cone he was given because the vanilla was sandwiched in the middle. He regularly asked for one specific item, and then one day the vendor changed what he was handing out without first checking to make sure it was OK. Customer walks up, expects to get what he's always gotten, and doesn't.

Doesn't matter that it's an allergy instead of just not liking vanilla. If the customer removes all the vanilla he can still eat the chocolate.

 

Now for a human this would be almost impossible, but for a computer program it is not. A computer program can filter out the parts it doesn't want. XML was explicitly designed to do this. If a program can't do this then the programmer deliberately imposed that restriction on it.

 

In the Delorme program, instead of continuing to the next section in the cache XML when encountering the unknown section the programmer on purpose decided to say "must not be a cache, waypoint only". This is not a accidental bug, it's a deliberate action on the part of the programmer. They chose to go against the XML standard.

 

All this does not excuse the fact that Groundspeak is showing people that they have a 1.0 preference, but they're handing out 1.0.1. It's completely misleading and false.

We're not arguing that point. I agree 100%.

[+Pax42]

Now I've got a hankering for ice cream; one scoop of vanilla, one scoop of chocolate, and one scoop of rocky road, mmm, mmm good.

[+Avernar]

If you did use the special spoon (perhaps one can even get this spoon for free) you would cetainly be able to tolerate certain kinds of changes to the ice cream. On the other hand, it might not be reasonable to expect every one to use this special spoon. Even if you can get a spoon for free, it might not fit in your pocket or it may be difficult for you to hold. Should the ice cream shop assume everyone uses a special spoon or should they try to let customers know in advance that the ingredients in the ice cream are changing?

You almost understand. Every XML parsing spoon can separate all the ingredients, from the fancy-shmancy one to the regular old spoon. The problem is not the XML parser, it's the code that's using the output of the parser.

 

What you're missing is that the user of the spoon is getting all these separated ingredients, sees all the ones he wants but just because there was something in there originally that he didn't want and even though it's separated out now chooses not to eat any of it.

 

There are a lot of things you can do to the XML file, here are some examples:

 

1) Removing or renaming a critical piece of information. Example: Renaming latitude and longitude to lat and long. Result: All programs will break.

 

2) Removing or renaming a optional piece of information. Example: Removing cache size. Result: Some programs break, others just set their cache size to Unknown.

 

3) Adding new items to existing sections. Example: Adding a new cache type. Result: Most programs work and set the type to "new cache type", a few break.

 

4) Adding a new section. Example: Adding cache attributes section. Result: No programs break.

 

If a program breaks because of 4 then the programmer did it on purpose.

[+tozainamboku]

 

4) Adding a new section. Example: Adding cache attributes section. Result: No programs break.

 

If a program breaks because of 4 then the programmer did it on purpose.

I can understand that the standard provides some rules so an XML schema will be extensible. After the X in XML stands for eXtensible. The standard may in fact state that an XML consumer MUST ignore unrecognized tags and any content between them. So in that respect a standards compliant XML parsing spoon has to separate out any new ingredient in the ice cream and the program using that spoon has to ignore the ingredient it doesn't want.

 

The problem is in the real world, people don't always create standards compliant XML consumers. If one doesn't expect the XML schema to change much, there are often very good reasons to be non-compliant. A custom parser is usually more efficieint and in a hand held device with limited memory and limited processor speed, there could be a valid reason to write a custom parser that fails if the schema is extended.

 

Should XML producers expect that everyone using their XML is using a standards compliant parser? I guess the idea is that if everyone followed the standard, they would all know what changes can be made in the schema without breaking other applications. On the other hand, extending a schema and not providing the information to consumers beforehand is pretty silly as well. If the consumers were to know the change were coming then both standard and not standard compliant applications could be changed to actually use the extended data.

 

In the end users generally care about whether two systems work together and not whether somebody was standards compliant. XML and agreed upon XML schema have simplified the problem of getting systems to work together greatly. And perhaps if everyone complied with the extensiblity rules in the standard, there would be a bit more tolerance if one side makes changes. But using standards to cast blame is counterproductive in individual cases. It would seem much more reasonable to let consumers know in advance the changes is comming and to work with then to schedule when the switchover occurs. If necessary the producer could provide different version of th file. In that case, it would seem more reasonable to default to the old version that works with everyone and let users who have application that actually are able to use the newer version select it.

[+pppingme]

But everyone is dogpiling on DeLorme here over the XML and ignoring the real issue which Groundspeak can address - for users who have not selected a GPX format, Groundspeak changed the default version they get from 1.0 to 1.0.1 without notice, and without any indication in the user's preferences. In your preferences, it still shows 1.0 if you haven't made a selection!

Why should gs spend ANY time implementing a work around for an already fragile PQ system? With the workaround, certain pieces of code have to be written twice, one for attributes, one for no attributes.

 

The reality should be, that gs pull the ability to choose, put the .gpx out with attributes, and quit wasting time on something that isn't their problem to start with.

 

PQ's are already fragile, gs need to spend time fixing that, and not waste time making work arounds for someone that can't properly read a xml file.

[+Pax42]

Why should gs spend ANY time implementing a work around for an already fragile PQ system? With the workaround, certain pieces of code have to be written twice, one for attributes, one for no attributes.

 

The reality should be, that gs pull the ability to choose, put the .gpx out with attributes, and quit wasting time on something that isn't their problem to start with.

 

PQ's are already fragile, gs need to spend time fixing that, and not waste time making work arounds for someone that can't properly read a xml file.

So by that logic, they should also stop providing .loc files, stop providing support for older browsers, and any of numerous other things that don't fit into what you personally find of value. They are a business trying to make some money. You need customers to make money. Not all customers are going to have the same tools. They're doing their best to support us all. I guess my needs and thousands of other customer's needs are just a waste of time.

[+pppingme]

So by that logic, they should also stop providing .loc files, stop providing support for older browsers, and any of numerous other things that don't fit into what you personally find of value. They are a business trying to make some money. You need customers to make money. Not all customers are going to have the same tools. They're doing their best to support us all. I guess my needs and thousands of other customer's needs are just a waste of time.

What about Delorme supporting their customers? After all, gs put out attributes on 1/12, thats two months ago, in the mean time, they've implemented a work around for Delorme's broken software (although the work around has been found to be buggy), DURING THAT TIME, WHAT HAS DELORME DONE TO FIX THE PROBLEM? From what I've seen, nothing.

 

This isn't a matter of what I find of value, its a matter of something that shouldn't have broken to start with because a 3rd party app doesn't correctly read the files, and now gs has had to waste development time dealing with the situation.

 

The site has to make progress, a broken 3rd party app should not keep progress away.

[2oldfarts (the rockhounders)]

This isn't a matter of what I find of value, its a matter of something that shouldn't have broken to start with because a 3rd party app doesn't correctly read the files, and now gs has had to waste development time dealing with the situation.

 

Simple solution is to set the default to 1.0 and not changing the default without letting the customer know it was changed!

 

I don't need or want the attributes in my PQs, but it seems GS knows what is best for me.

 

This seems to be a common affliction with GS. Making changes that create more problems for their customers. I think they believe change for the sake of change is good.

 

John

[+Avernar]

I can understand that the standard provides some rules so an XML schema will be extensible. After the X in XML stands for eXtensible. The standard may in fact state that an XML consumer MUST ignore unrecognized tags and any content between them. So in that respect a standards compliant XML parsing spoon has to separate out any new ingredient in the ice cream and the program using that spoon has to ignore the ingredient it doesn't want.

First a little GPX information. The GPX schema used by Groundspeak is version 1.0. It describes waypoints only. Groundpeak orignally added a new section to each waypoint in the file called "Groundspeak:cache" (the G should be lower case but the forum software is capitalizing it) with it's own schema and it had a version of 1.0. To add attributes, Groundspeak changed it's "Groundspeak:cache" schema to 1.0.1.

 

All program that can read GPX but don't understand the Groundspeak extensions, like Garmin Mapsource, just load the GPX file as waypoints ignoring the "Groundspeak:cache" section. Re-reading the first post in the thread, it looks like the Delorme program was using a standards compliant "fancy-smancy" XML parser. It detected the Groundspeak schema change and defaulted back to regual GPX mode and loaded the caches as waypoints. It did in face skip the unknown section, even though it could have read it no problem.

 

My issue is that they should have popped up a warning dialog informing the user that they detected the new schema and were defaulting to "waypoint only". Silently failing is bad programming.

 

The problem is in the real world, people don't always create standards compliant XML consumers. If one doesn't expect the XML schema to change much, there are often very good reasons to be non-compliant. A custom parser is usually more efficieint and in a hand held device with limited memory and limited processor speed, there could be a valid reason to write a custom parser that fails if the schema is extended.

The Delorme program was running on a PC. They have plenty of memory and processing power to warn the user they detected something wrong.

 

And the flaw with your argument is that a hand held device already does skip a lot of information in the GPX. The routine to skip a section is already there. But like I said, it was running on a PC.

 

Should XML producers expect that everyone using their XML is using a standards compliant parser? I guess the idea is that if everyone followed the standard, they would all know what changes can be made in the schema without breaking other applications.

The answer is yes since the parser only parses the file, it doesn't interpret the schema. But after thinking about it a bit, Groundspeak didn't extend the GPX in a backwards compatible way. It was in fact the less picky programs that had the least trouble.

 

What Groundspeak should have done was leave their Groundspeak:cache schema at 1.0 and created a new schema for the Groundspeak:attributes section. That way the strict XML compliant program would still read the Groundspeak:cache section but ignore the Groundspeak:attributes subsection.

 

On the other hand, extending a schema and not providing the information to consumers beforehand is pretty silly as well. If the consumers were to know the change were coming then both standard and not standard compliant applications could be changed to actually use the extended data.

Yes, putting in a new schema version and not providing warning to the consumers is silly.

 

But if they did it right and added a new section with it's own schema then letting people know whouldn't be necessary. But it would still be a good thing to do so.

Edited March 12, 2010 by Avernar

[+tozainamboku]

....

The answer is yes since the parser only parses the file, it doesn't interpret the schema. But after thinking about it a bit, Groundspeak didn't extend the GPX in a backwards compatible way. It was in fact the less picky programs that had the least trouble.

 

What Groundspeak should have done was leave their Groundspeak:cache schema at 1.0 and created a new schema for the Groundspeak:attributes section. That way the strict XML compliant program would still read the Groundspeak:cache section but ignore the Groundspeak:attributes subsection.

 

OK

 

So the ice cream used to come in a dish. Now they serve it in cone. After all a standards compliant customer would have seen the scoop of ice cream and said "I don't know what to do with the cone, so I'll ignore it. But I can still eat the ice cream". But what actually happened is that the ice cream cone came with a namespace reference for icecream/1.0.1. The customer said, I don't know about version 1.0.1 of ice cream so I will ignore everything in the icecream namespace. So he did as he was supposed to and ignored not only the cone but the scoop of ice cream as well.

 

Then the ice cream parlor said you can order your ice cream either in a dish (version 1.0) or in a cone (verision 1.0.1). But if you don't tell me which one you want, you will get it in a cone. And by they way, if you go to the page where I show your prefence and you haven't selected one yet, I'll show that you have selected a dish (version 1.0). That's just wrong.

[+Avernar]

So the ice cream used to come in a dish. Now they serve it in cone. After all a standards compliant customer would have seen the scoop of ice cream and said "I don't know what to do with the cone, so I'll ignore it. But I can still eat the ice cream". But what actually happened is that the ice cream cone came with a namespace reference for icecream/1.0.1. The customer said, I don't know about version 1.0.1 of ice cream so I will ignore everything in the icecream namespace. So he did as he was supposed to and ignored not only the cone but the scoop of ice cream as well.

This would be closer:

 

The ice cream 1.0 (cache) came in a cone (waypoint). The customer ate it all. Then they added sprinkles (attributes) to the ice cream making it 1.0.1. The standards compliant customer tosssed the new ice cream 1.0.1 and ate just the cone (waypoint). The less standards compliant ate the cone and ice cream 1.0.1 anyways and just spit out the sprinkles.

 

What they should have done was kept the cone (waypoint) and ice cream 1.0 (cache) and put the sprinkles (attributes) on the side in a small cup. Everyone would have been happy.

 

Then the ice cream parlor said you can order your ice cream either in a dish (version 1.0) or in a cone (verision 1.0.1). But if you don't tell me which one you want, you will get it in a cone. And by they way, if you go to the page where I show your prefence and you haven't selected one yet, I'll show that you have selected a dish (version 1.0). That's just wrong.

 

This part I agree with.

 

And now I have a hankering for ice cream...