Given the relaunch of OpenSearch, and given that OpenSearch results can be included in feeds, it seemed time to spend some of my recreational programming time on adding Feed Validator support for the OpenSearch namespace extensions.
The spec is cleanly written. It is organized as a series of small sections, each of which makes a few testable assertions, such as on the cardinality of the element, or restrictions on the value space.
This makes it easy to organize the test cases. Each section implented so far is represented by a hypertext link to a directory of tests for that section, and each directory listing contains a link to the corresponding section in the specification. Tests can be run by clicking on the green Universal Feed Icon next to the testcase itself.
My one quibble with the spec so far is that like Mark Nottingham, I have an aversion of usage of XML QNames as attribute values. At the moment, I haven’t coded these tests. My preference would be that this attribute be changed to a simple URI.
Perhaps the next time I get a few free cycles, I’ll not only complete this, but go on to add tests and code for the OpenSearch description document. My experience is that document formats that use mixed case names result is a significant contributor to common feed errors.
A huge thanks, Sam!
Your points about QNames are well taken, and I’ve tried to respond at length here:
http://blog.unto.net/opensearch/opensearch-support-added-to-the-feed-validator/
The actual changes need to remove qnames is rather small.
From:
<Url type="application/rss+xml" xmlns:example="http://example.com/opensearchextensions/1.0/" template="http://example.com?q={searchTerms}&c={example:color?}"/>
To:
<Url xmlns:os="http://a9.com/-/spec/opensearch/1.1/" type="application/rss+xml" os:example="http://example.com/opensearchextensions/1.0/ template="http://example.com?q={searchTerms}&c={example:color?}"/>
Joe,
I like the thinking behind your proposal, as it does keep the template parameters simple, but how do we deal with the fact that the namespace http://a9.com/-/spec/opensearch/1.1/
should not contain arbitrary attribute names? I.e., os:example
would not be allowed, unless I’m misunderstanding something.
I suppose we could introduce a new namespace, that would allow for arbitrary attribute names. Thus:
<Url xmlns:os="http://a9.com/-/spec/opensearch/1.1/extensions/" type="application/rss+xml" os:example="http://example.com/opensearchextensions/1.0/ template="http://example.com?q={searchTerms}&c={example:color?}"/>
The Feed Validator Documentation web page for OpenSearch still features a “RSS 2.0 Test Cases” paragraph at the top.
Fixed. Thanks!
I’ve also roughed in support for validating OpenSearch Description Documents. Anybody interested in creating an icon for valid OpenSearch documents?
DeWitt,
That works.
If this were to go into Open Search, what would the migration plan be?
Would OS add “os:” style extension attributes and deprecate qnames in one
version then remove qnames in the next version of the spec?
deprecate qnames
The feed validator could certainly issue warnings when the extension attribute isn’t present. In fact, for OpenSearch 1.1, it could also issue warnings if the qname prefix isn’t declared as a xmlns.
I’d also suggest that extension attributes be allowed to be on the OpenSearchDescription elements, and perhaps the Atom feed element and RSS 2.0 channel element.