|Sent:||1/13/2005 10:42:20 AM|
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?
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
> > locationless
> 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.