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:
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:
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?
One of the obvious and important aspects of URI Templates is how to express templates and their collection of template variables within XML. The two cases where this becomes immediately important are OpenSearch and CalAtom. There has been some...