Error in one of the tests (was Re: pyRdfa and the RDFa Test Suite)

Michael,

I looked at the test entry where pyRdfa really failed, and I realized
that the test is on hold but should also be rejected. Indeed, it uses
the form:

<link about="[_:a]" rel="foaf:knows" href="[_:b]" />

which is, afaik, wrong. The syntax defines @href as a URI, and not a
URIorCURIE. Ie, for the test above to be o.k., @resource should be used
and not @href...

Ivan

Ivan Herman wrote:
> Hi Ed,
> 
> (Michael, I explicitly copy you because there are issues/questions
> regarding the test cases that should be settled; thanks to Ed for
> bringing these to the fore!)
> 
> This is a useful addition! I have stored your setup files and others on
> my local disc. My problem for now is that the changes in pyRdfa are
> still way too frequent to make it so full packaged with proper versions.
> I would like to do that when both the syntax document and the
> implementation becomes a bit more stable and I will certainly used that
> setup at that point! Thanks!!!!
> 
> Of course, you touched on my own vanity:-) and I looked at the tests
> that did not work, running them manually one-by-one. _My_ overall
> judgement is, however, that most of the problems are related to the
> SPARQL (I may be wrong, of course!). Indeed, except for a few cases
> (noted below) my claim is that the pyRDFa is fine and conform to the
> test; in my view, the SPARQL processor should have accepted it.
> 
> There may be two problems/reasons:
> 
> - a genuine SPARQL error on our tests. Did we ever checked those with a
> processor, in fact?
> 
> - problems with RDFlib's SPARQL parser or implementation. A few words on
> that one: the irony is that the 'core' SPARQL processing in rdflib is my
> making... But then, lack of time, I never made a parser for the SPARQL
> language itself. Others did that, but because they used a binary parser,
> I could never run that on my windows machine... But the latest SPARQL
> test results (that the DAWG is preparing of the Proposed Recommendation
> phase of SPARQL) reveals that there are some more genuine problems with
> it...
> 
> I would probably prefer to run the results on a more reliable SPARQL
> implementation, eg, sparqler... Maybe my simple interface to SPARQL[1]
> may help in that.
> 
> Another comment: the test cases include a number of tests which are
> either not yet approved or, worse, rejected and/or on hold. Note to
> Michael: it might be a good idea to remove these from the manifest at
> some point...
> 
> Thanks again Ed,
> 
> Ivan
> 
> [1]
> http://ivanherman.wordpress.com/2007/07/06/sparql-endpoint-interface-to-python/
> 
> P.S. Just for completeness, my remarks below. All others either pass or,
> again in my view, have SPARQL problems...
> 
>> --
>>
>> test_0004 (test.XhtmlTests) ... FAIL
> 
> Test is on hold but, in fact, to be removed/rejected. We decided not to
> use @xml:base
> 
>> test_0005 (test.XhtmlTests) ... FAIL
> 
> Test is rejected
> 
>> test_0011 (test.XhtmlTests) ... FAIL
> 
> There is a pending question (in my mind at least) whether XMLLiterals
> should be "canonicalized" or not. This is the reason of the failure: I
> copy the XML Literal verbatim, whereas the test canonicalizes it.
> 
>> test_0017 (test.XhtmlTests) ... FAIL
> 
> Although this test is marked as 'on hold', it looks reasonable to me.
> But, indeed, it fails on pyRdfa, I will have to look into that...
> 
>> test_0022 (test.XhtmlTests) ... FAIL
> 
> This is unreviewed, but is definitely to be rejected. We decided not to
> use @id.
> 

-- 

Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf