Nigel Tao: we now support GeoRSS as a data format for geographic content in Google Maps. We want to enable users to create data in whatever format is most convenient for them, and feel that by supporting both KML and GeoRSS we can enable a wider variety of people and applications to contribute content to Google Maps. We’ve built support for the Simple, GML, and W3C Geo encodings of GeoRSS — all you have to do is enter the full URL of a GeoRSS file into the Maps query box to load the file. For example, take a look at SlashGeo’s GeoRSS on Google Maps.
Doubling back to validate the SlashGeo feed, and the result is two warnings. The first represents the transplanting of the controversial RSS 2.0 practice of double encoding titles as HTML — which is discouraged by a number of Google, Microsoft, and Mozilla tools — into the context of RSS 1.0. The second is the use of a comma as a separator for latitude and longitude values, where the spec requires whitespace. Another place in the spec requires a [single?] space. A third place in the documentation indicates that the preferred serialization of this uses a [single?] space to separate the two values.
Update: this latter issue has been addressed in the slashgeo feed. Thanks!
OK, but the SlashGeo feed is not only supported by Google, but held up as an exemplar, so I’ve downgraded the message that is produced when a comma appears where a space ought to be to a warning.
So, just when I think I’m done, and get ready to commit these changes, I find this:
For starters, does anybody know where dc:date.Taken is defined? If there is documentation, I will add support for it in the Feed Validator.
Update: as spotted by Kevin H, this is valid "Qualified" Dublin Core, and I’ve updated the feed validator to accept it.
But the more interesting one is the second error. It points to georss:point and says that geo:point is undefined. Looking further, we find that while the GeoRSS spec suggests:
These two namespaces aren’t compatible. The W3C Geo spec defines a Point with a capital P and utilizes nested child elements (per this example), and Simple GeoRSS defines a point with a lowercase p, and omits the child elements (per this example).
If anybody can shed any further light on this, please either leave a comment here or on the feedvalidators-users mailing list; the latter I am seriously considering shutting down and moving the whole Feed Validator project to Google Code as the mailinglist is being overrun by spammers.
The slashgeo feed was a random choice, I think, not an exemplar.
I assert that examples that are pointed to by Google, and supported by Google Maps, will be imitated, are (or will become) representative, will serve as a pattern that others will follow, and copied.
In short, Nigel’s post has (undoubtedly inadvertently) effectively promoted the SlashGeo feed as an exemplar.
Thanks for telling us. slashcode’s GeoRSS feed plugin is in development, it is not considered completed yet. We’ll fix the issues - thanks for mentioning them! :-)
The guiding principle for the qualification of Dublin Core elements, colloquially known as the Dumb-Down Principle, is that a client should be able to ignore any qualifier and use the description as if it were unqualified. While this may result in some loss of specificity, the remaining element value (without the qualifier) should continue to be generally correct and useful for discovery. (source)
I would expect the FeedValidator to throw no more than a warning, so long as the unqualified element is part of Dublin Core.
I would expect the FeedValidator to throw no more than a warning, so long as the unqualified element is part of Dublin Core.
I’ve updated the Feed Validator to accept without warning qualified elements, but only for the Dublin Core namespace, and only if the unqualified element would otherwise be accepted by the Feed Validator.
I’m sorry to say it, but I fear I may have steered you wrong. What nagged at me after submitting my last comment was that I never did find any recommendation on how element refinements should be represented in an XML context.
I’m a bit confused, now, if the recommendation even allows arbitrary extension, considering this MUST:
- Each property must be either:
one of the 15 DC elements,
one of the other elements recommended by the DCMI (e.g. audience) [DCTERMS],
one of the element refinements listed in the DCMI Metadata Terms recommendation [DCTERMS].
But some hope is given in Recommendation 8, with this SHOULD:
Element refinements and encoding schemes should use the names specified in the DCMI Metadata Terms recommendation
I’ll also mention, since I happened across it, that the “Date.Taken” dot-notation seems to have lost favor even in HTML/XHTML meta and link elements:
2. Previous recommendations specified prefixing element refinements by the element
being refined, for example 'DC.Date.modified' rather than 'DCTERMS.modified'.
These forms of encoding are acceptable but are no longer considered the preferred form.
transplanting of the controversial RSS 2.0 practice of double encoding titles as HTML
Where in the RSS spec is this specified?
We design our RSS so that the result can be dropped right into HTML. There is no standard for this in the spec, but it was discussed on the rss-dev mailing list awhile back, and there were several
proponents for the method we use.
There is no standard for this in the spec, but it was discussed on the rss-dev mailing list awhile back, and there were several proponents for the method we use.
Lift Web Framework I’ve begun considering what language and/or framework to learn next. I doubt it’ll be Scala, but this does sound interesting. (tags: frameworks lift scala) Dean Edwards: Yet Another JavaScript Library Without Documentation “This...
O’Reilly’s Where 2.0 Conference isn’t until the end of May, but Google just released two sweet new map-related features: GeoRSS support and MyMaps. The GeoRSS support means that any application that can output it’s geocoding...
Mainly being geoRSS update and more location information goodness for you in the flickr.photo.getInfo call.1.... If the photo has been dropped onto the map from a fairly high level you may only get region or country.We’re still recording the...
To be precise, I’m on the Slashdot , which means I now have +1 Nerd Cred. Admittedly, it popped up on Easter Friday, which would probably be in the top 3 slowest news days of the year. And you have to dive in to the numerous links (no, not from a...
O’Reilly’s Where 2.0 Conference isn’t until the end of May, but Google just released two sweet new map-related features: GeoRSS support and MyMaps. The GeoRSS support means that any application that can output it’s geocoding...
To be precise, I’m on the Slashdot, which means I now have +1 Nerd Cred. Admittedly, it popped up on Easter Friday, which would probably be in the top 3 slowest news days of the year. And you have to dive in to the numerous links (no, not...