From:
"Robert Lipe" <robertlipe@usa.net>
Sent: 1/13/2005 10:42:20 AM
To:
gpsstash@yahoogroups.com
Cc:
Bcc:
Subject:

Re: GPX standard extensions




> consumer. If the consumers (e.g., GpsBabel) publish an open standard
> that their tools will accept, I'll bend over backwards to try to
> produce that format.

I intend to play the "not my problem" card on this one. I'll help
review things and I'll even implement the code for ONE such extension,
but I'm really not going to be the one to drive it.

> I offered the GPX that GPSgames.org currently
> produces in hopes of speeding the process up.

I agree the IETF model ("rough consensus and working prototypes") is
the way to make this happen in the least painful way.


> days. I believe the version currently posted passes SAX2Count

Lovely. Thanx.

It's less important that it SAX2Count's at any moment in time than
that you're attuned to the need for it pass validation and it sounds
like you're hip with that.

> > It's interesting that you based it on GPX 1.0 instead of GPX 1.1.
> That was just an oversight. I'm not familiar with the differences.

They were discussed on the GPX developer yahoogroup (sigh) before it
was published. Archives should be there, but the schema was
published some time ago.

I should confess that only recently have I seen the need to add GPX
1.1 to GPSBabel.


> The logs in the GPSgames.org GPX files should always be treated as
> HTML. They don't always have HTML markup in them, but they are all
> treated as HTML when displayed on the site. I'll look into how to

Therefore consumers of this data are not expected to preserve vertical
whitespace in the logs and since
and

tags are rare, most of
the things that look to the human observer as paragraph markers are
expected to be collapsed into a single block, right?

For example:

cache, besides the possibility of muggles being around periodically.

When you find this cache, you should know why it is called the &qu

should therefore be run together...


> > two encodings that have to be individually parsed: it looks like
> > you have to HTML parse it FIRST and then rot13 parse it.
>
> That is correct. I guess the point was not to have the plaintext hint
> in the GPX. Hand the HTML-encoded hint to your widget and display the
> encrypted hint, the same way the Web site does.

Display choices should be made at the client end, not in the data
encoding. If the program want to display it obscured in some way,
that should be its choice.

> > I could make a type of regular hitchhiker multi webcam
> > locationless which would be legal but kind of paradoxical.
>
> Well... I'm not sure you can create mutually exclusive subsets. For

I think I understand what you're trying to do (probably because you've
observed the same limitations on "prior art" for this that I have) but
you may have opened the door wider than you intended in the XSD.

> That was the thinking anyway. If the majority of sites/programs
> really think it makes sense to create mutually exclusive types, I can
> find a best fit for whatever boxes some user of GPSgames.org might

Think about a program trying to write helpful icons to a receiver (and
I fully understand that's a less expressive media than either a web
browser or english text) and see if you agree that some degree of
categorization would be helpful.

> I'll go where the traffic is. The Yahoo ads at the bottom of the
> emails never bothered me, personally.

Procmail ensures I never see those.

> And the spams that come to this
> list could be controlled if the list owner was active and cared to.

Looking at the archives, it seems those conditions are false.