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

[Andrew Turner]

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