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? 

<rant>

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.

</rant>

Mark Birbeck wrote:
Hi Philip,

On Fri, Sep 4, 2009 at 2:17 PM, Philip Taylor<pjt47@cam.ac.uk> wrote:
  
[snip]

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.
    

Yes, definitely.

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.

Regards,

Mark

  

-- 
Shane P. McCarron                          Phone: +1 763 786-8160 x120
Managing Director                            Fax: +1 763 786-8180
ApTest Minnesota                            Inet: shane@aptest.com