[georss] kml reference placemarks v/ georss?

[josh at oklieb.net]

The interesting part is not the href but the rel attribute. One can put a
WFS GetFeature call or a NetworkLink endpoint into an href. The rel
attribute (defined in a profile element) should then describe it so that
that a client knows, for example, to append a bounding box to the end of
the URL before resolving it. One doesn't need to click on too many
100-megabyte documents at the end of an href to realize that more
discriminating link resolution behavior is needed in a web of data,
geographic or otherwise.

BTW, KML files can already reference other KML files - this is how imagery
"superlayers" are set up. GML and GeoRSS can do the same in one way or
another. Characterizing the references so that clients can do something
reasonable with them is still an interoperability challenge.

Josh

> josh at oklieb.net wrote:
>>> sgillies at frii.com wrote:
>>>
>>>> Gregor,
>>>>
>>>> The divide between HTML links and KML network links should be closed,
>>>> with
>>>> KML joining the existing Web. Ditch <NetworkLink> for <a
>>>> rel="KML-Link">
>>>> or something like that. Nevermind WFS, there's no web there.
>>> the only problem with that is that NetworkLink specifies a lot of
>>> behavior for these links. in order to preserve that, it would have to
>>> be
>>> <a rel="KML-link"><someoptiontag>
>>>
>>> this quickly gets unwieldy. which is presumably why NetworkLink was
>>> invented :)
>>
>> Strangely enough (and earlier), also why WFS was invented. ;)
>
> i see :) still, what can we do to encourage linking of even the most
> basic sort? clearly it has been very beneficial on the web despite the
> limatations of <a href. interestingly, better linking specs never went
> anywhere.
>
>