[georss] WAS: GeoRSS Validation Service? RETURNING TO: multiple locations and time

[Andrew Turner]

On 2/28/07, Mikel Maron <mikel_maron at yahoo.com> wrote:
>
> Nice initiative, to pull the discussions into more referencible artifacts.
> My concern is that an html faq page may quickly grow stale, and that not
> everyone has access to it.
> Perhaps we could have an "FAQ" category on the blog, and focus artifacting
> there. Or maybe in trac?

Yes, the "staleness" was a thought I had with making it an HTML page -
and also its worth making sure that these 'solutions' aren't really
part of the standard (which maybe the HTML page would imply) vs. the
trac/wiki which is more community on the 'edge' of the standard.

Also, but using the trac/wiki it allows the discussion to continue -
where so far on email the discussions get sidetracked or cutoff
without real resolution. And finding them in the digests isn't always
the easiest thing.

The blog is good - but almost too transitory - so probably a blog
entry summing it up and pointing to a wiki page in trac  that can be
edited by others as the discussion on the topics continue.

However, I wanted to get something up so that we could move to finding
a solution for these great ideas and notes. Especially since people
like Brian are under a real-deadline to produce for a customer whereas
a standard isn't. :)

Andrew

> ----- Original Message ----
> From: Andrew Turner <georss at highearthorbit.com>
> To: "Knoth, Brian D." <bknoth at mitre.org>
> Cc: georss at lists.eogeo.org
> Sent: Wednesday, February 28, 2007 1:38:44 PM
> Subject: Re: [georss] WAS: GeoRSS Validation Service? RETURNING TO: multiple
> locations and time
>
>
> On 2/27/07, Knoth, Brian D. <bknoth at mitre.org> wrote:
> > Peter,
> >
> > In any regard, I did not make any progress with this argument here
> > (even after receiving a favorable vote for the capability). So, like
> > you, we will need to abandon geoRSS in favor of a more expressive
> > implementation.
> >
>
> There are many ideas and needs that come across GeoRSS that fail to
> make it into the standard for whatever reason.
>
> What seems beneficial is to maintain a FAQ or history of
> requests/proposals, their outcomes, and reasonings. And finally, if it
> is not accepted *into* the standard, what people that are working
> outside the 'standard' are all adopting.
>
> That way, if/when the discussion comes up again, we can point to the
> 'best suggested alternative' that others are using. Others running
> into the same issue can use the common solution - and anyone building
> tools can try and accommodate these cases.   And if that feature does
> make it into the standard, everyone that was using that ad-hoc
> solution can make the same transformation into the new standard (which
> would have accounted for what people have been doing in the meantime).
>
> This was illustrated by the Geonames discussion. Location names was
> deemed to not make it into GeoRSS, so everyone that needed it is using
> the Geonames namespace for location names.
>
> I've started to put these up on a FAQ page if that's ok:
> http://georss.org/faq.html
> Andrew
>
>
> On 2/28/07, Knoth, Brian D. <bknoth at mitre.org> wrote:
> > Josh,
> >
> > If by Give-and-Take, you mean that I should go off and implement my own
> > extension(s) or utilize some combination of existing extensions for
> > time windows and locations (while providing a loose referential linking
> > between them) to support what I need, then I feel I have been very
> > accommodating this. These are the suggestions that I've received and
> > I'm being forced to accept them because my original recommendation to
> > this mailing list of simply allowing the GML representation of space
> > with time in the geoRSS profile has been discarded.
> >
> > I just don't understand how an extension whose main purpose which is to
> > represent location (ie, geoRSS:where) can ignore the fact that stuff is
> > at a place at a specific time, usually for a period of time, and then
> > at some other place for other period of time. This fact just seems so
> > basic that to ignore it seriously limits the applicability of geoRSS to
> > anything more than possibly just the world of blogging. GE does a great
> > job of activating and deactivating things that are outside of their
> > time windows when TimePeriods are specified in KML. I've heard some
> > unsubstantiated rumors that GE may support geoRSS in the future - if
> > that is the case, shouldn't the hooks at least be inserted into geoRSS
> > now to begin preparing for that usage?
> >
> > So you are absolutely correct...I can build proprietary extensions and
> > mechanisms for supporting this in our RSS feeds. I have felt, and still
> > strongly do feel, that the proper place for this is within a maturing
> > RSS extension such as geoRSS which, hopefully for its own adoption
> > sake, can provide the building blocks necessary to support
> > functionality required by not only the Flikrs and blogs, but also
> > Enterprise RSS as well.
> >
> > VR
> > brian
> > _______________________________________________
> > georss mailing list
> > georss at lists.eogeo.org
> > http://lists.eogeo.org/mailman/listinfo/georss
> >
>
>
> --
> Andrew Turner
> ajturner at highearthorbit.com        42.4266N x 83.4931W
> http://highearthorbit.com              Northville, Michigan, USA
> _______________________________________________
> georss mailing list
> georss at lists.eogeo.org
> http://lists.eogeo.org/mailman/listinfo/georss
>
>


-- 
Andrew Turner
ajturner at highearthorbit.com        42.4266N x 83.4931W
http://highearthorbit.com              Northville, Michigan, USA