Re: RDFa test cases

Philip,

On 23 Sep 2009, at 09:07, Philip Taylor wrote:
> Jeni Tennison wrote:
>> Philip,
>> I just updated rdfQuery to address some of the new test cases that  
>> you've done. Thank you for taking the time to make the edge cases  
>> explicit. The latest trunk rdfQuery output will differ from the  
>> samples you give in some places, so just to detail them here and  
>> explain why:
>
> Great, thanks for looking at this! I've made a few changes to the test
> cases, and updated the test results to use the current trunk.

Thanks :) And thanks for the inclusion of the Opera results. It might  
be interesting to include results for other browsers too.

>> 2. For 'Underscore xmlns prefix', where the test case is:
>>  <p xmlns:_="http://example.org/" property="_:test">Test</p>
>> rdfQuery retains the legal namespace declaration but because the  
>> CURIE begins with _:, which is how blank nodes are indicated, it's  
>> interpreted as a blank node with the id 'test'. Predicates cannot  
>> be blank nodes in rdfQuery, so it's treated as a bogus value and  
>> ignored. No triples are created.
>
> I don't see anything in the RDFa spec that justifies this behaviour.  
> As
> far as I can tell, xmlns:_ updates the list of in-scope mappings, and
> then the CURIE is converted to URI with the steps "Split the CURIE at
> the colon to obtain the prefix and the resource. Using the prefix and
> the current in-scope mappings, obtain the URI that the prefix maps to.
> Concatenate the mapped URI with the resource value, to obtain an
> absolute URI". The prefix is '_' and so the relevant in-scope mapping
> applies, just like any other prefix, so the mapped URI comes from
> xmlns:_ and the resulting absolute URI is used as the predicate.
>
> This doesn't really sound like sensible behaviour, but it's how I
> interpret the spec. Am I misunderstanding something? Does the spec  
> need
> to be fixed?

Well, in Section 7 of the RDFa syntax specification [1] it says:

   "In normal evaluation of CURIEs the following context information
   would need to be provided:
   ...
     * a mapping to use with the '_' prefix, which is used to generate
       unique identifiers (for example, _:p).
   ...
   In RDFa these values are defined as follows:
   ...
     * the mapping to use with the '_' prefix, is not explicitly stated,
       but since it is used to generate [bnode]s, its implementation  
needs
       to be compatible with the RDF definition."

So it seems to me that RDFa holds the '_' prefix in special regard,  
thinks that the CURIE specification holds the '_' prefix in special  
regard, believes that it should not be interpreted in the same way as  
other prefixes, and that it's used to generate bnodes.

What I wish is that the CURIE specification said something clearly  
about the priority between "the mapping to use with the '_' prefix"  
and the "set of mappings from prefixes to URIs". All it says is [2]:

   "The CURIE prefix '_' is reserved for use by languages that support  
RDF.
    For this reason, the prefix '_' SHOULD be avoided by authors."

My interpretation is that 'reserved' means that the special use of '_'  
takes precedence over any other prefix mappings that may be provided  
to it.

I do think the CURIE specification could be improved by defining in  
much clearer language the four context items that the RDFa  
specification states are used to interpret CURIEs.

>> 3. For 'xmlns prefix 'xml' with incorrect URI', where the test case  
>> is:
>>  <p xmlns:xml="http://example.org/" property="xml:test">Test</p>
>> rdfQuery ignores the bogus namespace declaration, but uses the  
>> built-in namespace declaration for the prefix 'xml' and therefore  
>> generates the triple:
>>  <> <http://www.w3.org/XML/1998/namespacetest> "Test" .
>
> What built-in namespace declaration? The spec says there is "An
> initially empty list of [URI mapping]s, called the [local list of URI
> mappings]", and the list is only updated by xmlns:* attributes on
> processed elements, so it sounds like a violation if the list has some
> built-in entries and is not initially empty.
>
> Same issue for the tests that use xmlns:xmlns="...".
>
> The only one that should generate triples is
> xmlns:xml="http://www.w3.org/XML/1998/namespace" -- XML Namespaces  
> says
> the xml prefix/URI "MAY, but need not, be declared, and MUST NOT be
> bound to any other namespace name", so this particular declaration is
> legitimate and should add to the list of URI mappings. (It looks like
> rdfQuery is only accidentally passing this test, because of the  
> built-in
> mapping for xml, so the bugs are cancelling each other out :-) )

Yes. Short answer is that I don't know what should happen here, and I  
deliberately chose to take a different position from your test in the  
hope that someone on the RDFa TF would clarify what the correct  
interpretation is. Perhaps that was too subtle. I'll post a separate  
mail to explicitly call it out.

>> 8. The language-based tests aren't met, because I'm currently at a  
>> loss as to how to amend rdfQuery to work out whether it's being  
>> used in an HTML or XHTML setting and therefore whether xml:lang is  
>> a lang attribute in the XML namespace or an attribute called  
>> 'xml:lang' in no namespace.
>
> You shouldn't need to know the setting.
> http://whatwg.org/html5#language defines the language of an element in
> terms of the DOM, independent of the syntax, so it's the same for
> documents parsed from HTML and XHTML.

Yes, it would be nice if I could take that attitude. Even nicer if I  
could rely on the DOM's lang property. I'm just not quite sure how to  
square it with the requirement to work in legacy browsers (such as IE).

> On a related note, I fixed one of my language test cases (the input
> markup <p property=... xml:lang="aa">Test</p> in text/html ought to
> produce a literal with no language), and I think the rest are all
> testing for the correct output (per HTML5's definition of language).


OK.

Jeni

[1]: http://www.w3.org/TR/rdfa-syntax/#s_curies
[2]: http://www.w3.org/TR/curie/#s_syntax
-- 
Jeni Tennison
http://www.jenitennison.com

Received on Wednesday, 23 September 2009 13:22:36 UTC