Re: [Gpsbabel-code] gpx writer and xsi:schemaLocation

[tsteven4 <tst...@gm...>]

Thanks, I will vaporize the xsi:schemaLocation attributes.  I will 
probably roll this in with other changes to the gpx element attributes 
including a scan of xmlns values from the reader for passthrough 
support.  The QXmlStreamAttributes class should make the xmlns thing 
very straightforward on read.   We can use the writeAttributes method if 
we don't insist on newlines between the xmlns attributes.  
writeAttributes could be overridden but unless there is a strong 
argument for the newlines in the gpx start tag I don't want to bother.  
I plan to get rid of the  other forced newlines in the gpx start tag as 
well.  I want to do it all at once to minimize the number of thrashes of 
the reference files, it looks like ~139 reference files will need to 
change.  So while I sort of liked the newlines in the gpx start tag I am 
ready to accept what the QXmlStreamWriter formatting wants to do.

On 3/13/2013 10:53 AM, Robert Lipe wrote:
>
>
>
> On Tue, Mar 12, 2013 at 8:24 PM, tsteven4 <tst...@gm... 
> <mailto:tst...@gm...>> wrote:
>
>     Why are we torturing ourselves trying to output xsi:schemaLocation
>     attributes for the gpx element?
>
>
> That's a great question.
>
> In the early days of GPX - which was kind of early days of XML - there 
> was belief that tying the schema to the doc would make it self 
> describing.  This, of course, turned out to be just plain wrong for 
> anything more complicated than a glorified text editor that only 
> needed to know "this is a float and it's called altitude" while any 
> real app needed to actually understand what an alt was, how to splash 
> it onto a map, how to do nerdy math stuff with it, etc.   So the 
> suffering you see in the code is me clutching to the belief that these 
> should be preserved and trying to handle things like merging a GPX 1.0 
> and 1.1 file and so on.  I never really bought into the whole concept, 
> but I kept trying to support it and the code that tried to handle it 
> grew increasingly tortured.  You can see that angst in the comments 
> you cite.
>
> Just a couple of years ago, I was talking to some KML wizards - the 
> ones that got it formalized by the Open Geospatial Consortium - about 
> what a mess this schema was for us in KML and they looked at me like I 
> had three heads.  "Sane programs don't write that."  I dropped it from 
> the KML writer and nobody noticed.  (Well, you noticed, but nobody 
> actually missed it...)  It's probably time to let this go in GPX, too.
>
> I have no particular bond to this attribute. I support your proposal 
> to vaporize it.   If you'd like to be the executioner, feel free.
>
>     Robert, I see you chimed into emails about this in 2002 before
>     there was a 1.0 gpx schema.
>
>
> Just as a historic note, I was working with Dan and the others on what 
> became GPX long before GPX 1.0 was finalized.  Dan did a lot of the 
> prototyping in EasyGPS/ExpertGPS, but GPSBabel was the only open 
> source, cross platform program that would process that newfangled GPX, 
> so we really were the first two programs to prove that GPX could 
> transparently move data between programs.  Those independent 
> implementations really helped us prove the design.  GPX is now the 
> interface to most of the better GPSes around and even programs with 
> notoriously painful proprietary data formats (Streets & Trips, 
> Mapsource/Basecamp, Street Atlas, etc.) now use it and it's wildly 
> popular.  Even Microsoft calls it "cool". 
> http://www.microsoft.com/streets/en-us/gpx-what-is-it-and-why-it-is-cool.aspx 
>  I'm pretty proud to have helped that effort at such an influential stage.
>
>