Jump to content

deercreekth

+Premium Members
  • Posts

    212
  • Joined

  • Last visited

Posts posted by deercreekth

  1. Yeah but if you change the content of a node or attribute, you can easily hose a consumer of your XML.

    A casual look over a GPX generated before and after the changes suggests that the content of the nodes has not been modified, only the attributes node (and children) has been added. Honestly, it looks like several companies who should know better have coded lazy XML parsers that rely on the structure of the file to interpret correctly. The software apps are easily fixed by their vendors, of course, but it's rather embarrassing for them...

     

    I'll admit that I've always looked at XML files as glorified text files. Yeah, it's neat that you can use some XML parser to pull in the data. But it's always been easier for me to just parse the data myself without that overhead. I can pull out what I need and ignore the rest. As long as the tags I'm looking for don't change, I'm good to go. The way post 18 makes it sound, it is the content that's a problem. In particular, the change from "xmlns:Groundspeak="http://www.Groundspeak.com/cache/1/0" to "xmlns:Groundspeak="http://www.Groundspeak.com/cache/1/0/1". It seems weird to me that that would be a problem.

     

    For some of these companies you speak of, it's not so easy to just modify their applications to get around the structure change. Some of them have non-trivial processes to go through before releasing a change. They don't all have the luxury of being able to just throw a change out there without considering the consequences.

     

    If anyone should feel embarrassed about this, it's Groundspeak. If it were me, I'd be bouncing potential changes to my main data file structure off of my trusted partners before implementing them. A simple, "Hey, what happens if you try to process a file that looks like this?..." would have gone a long way.

     

    I'm hoping that if DeLorme ends up making changes, something good comes out of all of this. Being able to see cache attributes on my PN-40 would rock.

     

    The first bold is the version number of the Groundspeak extensions. It is correct for them to add the /1 to the end as they have added an extension to the "extensionable markup language"

     

    The company that made the reader is coded WRONG from the beginning. Since the attributes that were in the old GPX files haven't changed the reader should have been coded for those attributes.

     

    As an analogy lets talk about a fictional automobile XML file.

     

    A car maker makes a car and has a XML file describing it. In the XML file it has a attribute for <left door> and <right door> the possible content is yes or no.

     

    The XML file reads like this

    <car model>Runabout</car model>

    <left door>yes</left door>

    <right door>no</right door>

    </car>

     

    The car designer decides that he would like to tell you if the door is a suicide door or not in the XML file. He properly adds a new extension <style> the possible content is standard or suicide

     

    So the new file reads

     

    <car model>Runabout</car model>

    <left door>yes</left door>

    <style>standard</style>

    <right door>no</right door>

    <style>standard</style>

    </car>

     

    So on the part of the reader.

     

    Car company Yarmen made a reader that looked for the extension <left door> and <right door>. When the extension was added their reader still worked because the left and right extensions haven't changed.

     

    Car company Delord made a reader that said look at the first and second extension after the car model. When the extension was added their reader returned a value of yes and standard. Ooops that isn't a valid response for <right door>! So their reader didn't know what to return to the user of the reader. The Delord users were outraged that the car designer broke his file and demanded a change back to the old way.

     

    Both developers have the standards documentation that tells them that a child extension can be added but the second decided it would be easier to code on number of extensions instead of the correct method of coding for the extension names.

     

    In the meantime my door was smashed in and I couldn't get a replacement for it because no one knew if it was a suicide or standard door.

     

    Note, I know that much of this isn't correct as far as a valid XML file goes. It is intended as an example and may not even be correct as to why the Delord reader isn't working. It is intended just to show that the fault is not on the part of the car designer Dirttalk

     

    Ok, if you want to do car company analogies, I can do car company analogies. Let's say an automotive parts supplier were to print labels using the latest ANSI standard Data Matrix bar codes that meet the specifications laid out in the customer print and shipped them to a car manufacturer. Let's say that manufacturer has trouble reading some labels. They complain to the automotive parts supplier. It turns out that the automotive parts supplier is using fairly new standard equipment to print the labels and to read the labels several times before they leave their plant. Let's say the car manufacturer is using 10 year old plus scanners to read these labels. They could upgrade their equipment, or they could force the part supplier to change their process. This could have been avoided if the part supplier had provided samples for the car manufacturer to test prior to production.

     

    Also, if the parts supplier were to make a schema change such as the one you speak of, they would have to get customer approval prior to making the change. Doing something that breaks a customer's system without informing them of the change is generally frowned upon in the automotive industry, no matter how old their equipment/poor their code is.

  2. If anyone should feel embarrassed about this, it's Groundspeak. If it were me, I'd be bouncing potential changes to my main data file structure off of my trusted partners before implementing them.

    Point is they shouldn't have to. It's Groundspeak's job to provide the data in valid XML (which they do) and the software/firmware developer's job to provide a XML parser rather than a lazy parser that assumes a given structure. If vendors don't understand how XML works and how it should be parsed or just don't make the effort to do it properly, release a product anyway and end up with egg on their face, that's not Groundspeak's problem.

     

    I would appeal to Groundspeak to stand firm on this one and not be tempted to rollback for compatibility. If the companies in question care for their users, they'll push updates fairly quickly, I'd expect.

     

    My point is it's a bad idea to assume anything about how someone else's code is going to handle even what may be considered a trivial change. You can get on the XML high horse all you want, but it's just common courtesy to give someone a head's up before you push an update that could potentially break their stuff.

     

    Hey, I like the idea of the new additions. I'm more concerned with how this is handled in the future. If there's something that Groundspeak feels their trusted partners should do codewise to prevent this from happening in the future, I would hope they would communicate that with them. If not, at least give them advance warning when GPX format changes are coming.

  3. Yeah but if you change the content of a node or attribute, you can easily hose a consumer of your XML.

    A casual look over a GPX generated before and after the changes suggests that the content of the nodes has not been modified, only the attributes node (and children) has been added. Honestly, it looks like several companies who should know better have coded lazy XML parsers that rely on the structure of the file to interpret correctly. The software apps are easily fixed by their vendors, of course, but it's rather embarrassing for them...

     

    I'll admit that I've always looked at XML files as glorified text files. Yeah, it's neat that you can use some XML parser to pull in the data. But it's always been easier for me to just parse the data myself without that overhead. I can pull out what I need and ignore the rest. As long as the tags I'm looking for don't change, I'm good to go. The way post 18 makes it sound, it is the content that's a problem. In particular, the change from "xmlns:Groundspeak="http://www.Groundspeak.com/cache/1/0" to "xmlns:Groundspeak="http://www.Groundspeak.com/cache/1/0/1". It seems weird to me that that would be a problem.

     

    For some of these companies you speak of, it's not so easy to just modify their applications to get around the structure change. Some of them have non-trivial processes to go through before releasing a change. They don't all have the luxury of being able to just throw a change out there without considering the consequences.

     

    If anyone should feel embarrassed about this, it's Groundspeak. If it were me, I'd be bouncing potential changes to my main data file structure off of my trusted partners before implementing them. A simple, "Hey, what happens if you try to process a file that looks like this?..." would have gone a long way.

     

    I'm hoping that if DeLorme ends up making changes, something good comes out of all of this. Being able to see cache attributes on my PN-40 would rock.

  4. I went to a local outdoor store to buy some waterproof casual shoes that will hopefully last a whole fall/winter yesterday. I noticed that the girl helping me had what looked like toe socks on. But they looked more like shoes than socks. I never did ask her what they were, but now I think they were these. They look like they would make awesome water shoes. I usually have to buy a cheap set of water shoes every year. I need a shoe, but I want to be barefoot. I may have to look into these.

  5. Thks for all answers. Seems clear to me but now I feel a lot better :). Will redirect here any new complain :P.

     

    The British woman in my GPS calls them roundabouts as well. I had never heard that term before. It's much better than annoying-circle-thingies-like-they-have-on-the-East-Coast, which is what I used to call them.

    Wikipedia is your friend Roundabout B):)

     

    Oooh, that article has another term the British woman in my GPS likes to use-- motorway.

  6. [Wow, there are so many! "His Favorite Niece" in Crown Hill is a wonderful virtual and I guarantee you'll enjoy the trip there.

     

    That is a beautiful spot. I did several in Crown Hill Cemetery a couple of weeks ago.

  7. If the cache is This sure Spruced Fortville up!, it should be obvious from the title and the hint that there's no need to trample on flowers. Unfortunately, adding something like "There's no need to trample on the flowers to find the cache" to the description probably wouldn't help, since they probably wouldn't read that either.

  8. I've had some of the power issues. Before I got a Li-Ion rechargeable battery pack, I had the unit freeze with alkalines a couple of times. I've had a couple of times where I couldn't get the unit to start without jumping through some hoops.

     

    I've only noticed signal loss once, while I was at the site of the second oldest cemetery in town. It was dropping like crazy there.

  9. I wouldn't call it a secret undocumented API. I'd say it's more of a non-public API documented well enough that a trusted partner(DeLorme) was able to utilize it with Cache Register. From the information given out by DeLorme before the release of Cache Register, it sounded like they were working closely with Groundspeak to make this happen.

  10.  

    Why is it sadistic to hide a cache in a tree? Some people consider caches like that fun. Not all caches have to be easy.

     

    Not "in a tree" but "up a tree". And yes, I know there are "some" who would enjoy those caches. I suppose it would be logical to assume, then, that the cache owner would be placing caches for a small majority, as opposed to the general caching community. Sounds a little selfish, and elitist, but its their deal, not mine.

     

    If I had a chainsaw, I would welcome the opportunity to use it.

  11. I bought some rare earth magnets from Harbor Freight Tools that were on sale for ~$1.20 for a 10 pack. I haven't had a chance to do anything with them yet. They also had the large 96 lb. pull magnets for $5.

×
×
  • Create New...