I would not object to providing examples of extraction algorithms as
guidance. We already do this for CURIEs somewhere... But I do not
think it is a good idea to normatively define code. The processing
model in the current RDFa Syntax Recommendation is sufficiently precise
for anyone to understand what must be done in the face of both
conforming and non-conforming input. The edge conditions people keep
bringing up (what happens if xmlns:="" is defined, etc) are all
degenerate cases of the general case of prefix declaration that does
not match the syntax definition. If it doesn't match the syntax
definition, it is illegal. If it is illegal, it is ignored. What more
does one need in a normative spec?
Let me beat this horse a little more. Not sure it is dead yet.
I could come up with a nearly infinite collection of illegal
declarations for each of the attributes that are addressed in the RDFa
Syntax specification. However, they would all fall into the same class
- illegal. When you are doing testing, you don't do "exhaustive" or
even "thorough" testing of anything that is sufficiently complex. It
is impossible. Instead, you do "equivalence class testing". Identify
a couple of use cases from each class of processing for a given
interface, test those, and trust that the other values in the class
will behave the same way. For example, I would not test every single
possible prefix name when exercising a CURIE processing library. It is
not just impossible, it is also uninteresting. I would test some good
ones and make sure they work. I would test some bad ones and make sure
they are ignored. Then I would move on.
If there are edge conditions that are not addressed by the eBNF in the
RDFa Syntax specification, we should fix the eBNF. If it is not clear
what one should do when presented with something that violates that
syntax, then we should fix that. That's the normative stuff. That's
what goes in a formal specification. Anything else, like guidance to
implementors about how to efficiently extract prefix definitions from
arbitrary input streams, goes into a note, or an implementors guide, or
someone's blog. Its not what formal specs do.
Mark Birbeck wrote:
On Fri, Sep 4, 2009 at 2:17 PM, Philip Taylor<firstname.lastname@example.org> wrote:
To make these kinds of bugs easy to identify and to avoid, I believe the
HTML5+RDFa draft really needs to define the prefix mapping extraction
algorithm in precise detail. Referring to the Namespaces in XML spec is
insufficient, because it's not clear how Namespaces in XML should be applied
to non-XML content, so HTML5+RDFa needs to make it clear itself.
Whilst I've not agreed with all of the points being made, it has
certainly become clear in this discussion that this whole area needs a
great deal more precision in any spec.
That's not just in HTML5+RDFa, but also in any future version of RDFa.
In fact, I'm even wondering whether the TF might want to consider an
errata on this.
Shane P. McCarron Phone: +1 763 786-8160 x120
Managing Director Fax: +1 763 786-8180
ApTest Minnesota Inet: email@example.com