RDFa Test Suite updates

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

RDFa Test Suite updates

Manu Sporny
There have been a number of Test Suite updates over the last two days
that affect approved and unapproved TCs:

http://github.com/msporny/rdfa-test-suite/commits/master

We had not been testing for the "first" reserved word in @rel/@rev. TCs
77 and 87 have been updated to include a test for the reserved word.
These tests are effectively our "reserved words" tests, so they should
have included "first" and not having it in there was an oversight that
has been corrected. If somebody could double-check that those tests are
still valid, and that I didn't mess anything up, that would be great.

http://github.com/msporny/rdfa-test-suite/commit/f6f7727bb3cf769b9c830ac88d8354e590e70f4f

TC115 had two issues. The first was an issue that would occur on
SAX-based processors that did not have access to the raw byte stream and
thus wouldn't be able to tell if the encoded "<strong>" value should be
interpreted as an XML Literal or not. The checking logs contain a bit
more information about the change:

http://github.com/msporny/rdfa-test-suite/commit/bfc4e3a6bc65ab67d73faa3b8d45f1f05e802293
http://github.com/msporny/rdfa-test-suite/commit/a27e4f4500a854024b0e3914af13f6227d54d805
http://github.com/msporny/rdfa-test-suite/commit/5e46f13b43a3e84e4e0ea15ebd297f9a88a4c3b8

TC 158 was merged with TC 164. TCs 147, 160, 162 and 164 were approved:

http://github.com/msporny/rdfa-test-suite/commit/bda9555239ee85d9066a54f70f17b249fd6b07fa

TC 142 and TC 154 have been moved to "On Hold" status. We need to
discuss an implementation issue with TC 142. LibXML (which has very
broad distribution - it's the Gnome projects XML library) currently has
a bug where it won't pass the xmlns:xml prefix to the RDFa processor.
This is an issue in Gregg Kellogg's Ruby RDFa parser and will certainly
be an issue in other parsers that use LibXML... we need to have somebody
contact that community and find out why they're not passing xmlns:xml,
and if it is a bug, ask them to correct the issue. TC 154 contains an
invalid XML character per XML 4th edition rules. We need to decide how
this will affect the graph that is generated and produce some errata
text to formalize the behavior.

-- manu

--
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: Establishing an Open Digital Media Commerce Standard
http://blog.digitalbazaar.com/2009/09/28/a-digital-content-commerce-standard/

Reply | Threaded
Open this post in threaded view
|

Re: RDFa Test Suite updates

Philip Taylor-5
Manu Sporny wrote:

> [...]
> TC115 had two issues. The first was an issue that would occur on
> SAX-based processors that did not have access to the raw byte stream and
> thus wouldn't be able to tell if the encoded "<strong>" value should be
> interpreted as an XML Literal or not. The checking logs contain a bit
> more information about the change:
>
> [...]
> http://github.com/msporny/rdfa-test-suite/commit/a27e4f4500a854024b0e3914af13f6227d54d805
> http://github.com/msporny/rdfa-test-suite/commit/5e46f13b43a3e84e4e0ea15ebd297f9a88a4c3b8

I don't understand the reasoning for this change, or why access to the
raw byte stream is relevant. The original test case said:

     <span property="ex:entity1">&lt;string&gt;</span>

so a SAX-based processor would see a stream like:

  * startElement("http://www.w3.org/1999/xhtml", "span", "span",
...attributes...)
  * characters("<string>")
  * endElement("http://www.w3.org/1999/xhtml", "span", "span")

Since the only event inside the element events is characters(), the
element clearly only contains text nodes, so it must be a plain literal.
If there were any startElement or processingInstruction events then it
would not be containing only text nodes, so it must be an XMLLiteral,
but that's not the case here. So I can't see what problem you were
trying to solve, since that test case seemed fine before - why was the
change needed?


This does suggest a new problem, though: what should be the output for:

     <span property="ex:entity1"><!-- comment -->string</span>

in any conforming RDFa processor? The RDFa spec talks about if "the
[current element] has any child nodes that are not simply text nodes",
and in a DOM-like or Infoset-like model there will typically be a
comment node (which is not a text node), so presumably this should be an
XMLLiteral. But the SAX2 ContentHandler interface does not expose
comments to the application, so it couldn't implement this in the same
way, so interoperability is lost. I guess it would be good to have a
test case for this.

--
Philip Taylor
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: RDFa Test Suite updates

Julian Reschke
Philip Taylor wrote:
> ...
> XMLLiteral. But the SAX2 ContentHandler interface does not expose
> comments to the application, so it couldn't implement this in the same
> ...

It doesn't???

BR, Julian

Reply | Threaded
Open this post in threaded view
|

Re: RDFa Test Suite updates

Philip Taylor-5
Julian Reschke wrote:
> Philip Taylor wrote:
>> ...
>> XMLLiteral. But the SAX2 ContentHandler interface does not expose
>> comments to the application, so it couldn't implement this in the same
>> ...
>
> It doesn't???

http://www.saxproject.org/apidoc/org/xml/sax/ContentHandler.html says it
doesn't. It is only exposed by
http://www.saxproject.org/apidoc/org/xml/sax/ext/LexicalHandler.html --
implementations that have that "optional extension" are okay (and I
assume that includes most practical implementations) but there's at
least a hypothetical concern for "core-only SAX2"-based RDFa
implementations, and it would be good to clarify the situation by adding
it to the test suite and seeing if implementors are happy with it.

--
Philip Taylor
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: RDFa Test Suite updates

Julian Reschke
Philip Taylor wrote:

> Julian Reschke wrote:
>> Philip Taylor wrote:
>>> ...
>>> XMLLiteral. But the SAX2 ContentHandler interface does not expose
>>> comments to the application, so it couldn't implement this in the
>>> same ...
>>
>> It doesn't???
>
> http://www.saxproject.org/apidoc/org/xml/sax/ContentHandler.html says it
> doesn't. It is only exposed by
> http://www.saxproject.org/apidoc/org/xml/sax/ext/LexicalHandler.html --
> implementations that have that "optional extension" are okay (and I
> assume that includes most practical implementations) but there's at
> least a hypothetical concern for "core-only SAX2"-based RDFa
> implementations, and it would be good to clarify the situation by adding
> it to the test suite and seeing if implementors are happy with it.

That's what I though: you can get comments, but it's not the default.

I think what's really important is whether comments (and PIs) should
trigger XMLLiterals; maybe they shouldn't?

Best regards, Julian


Reply | Threaded
Open this post in threaded view
|

Proposed new test cases (Was: Re: RDFa Test Suite updates)

Philip Taylor-5
Julian Reschke wrote:
> [...]
> I think what's really important is whether comments (and PIs) should
> trigger XMLLiterals; maybe they shouldn't?

I don't have a view on that, but it should be clear and consistently
implemented, so here's some suggested test cases (in roughly the
http://github.com/msporny/rdfa-test-suite/ format) which I believe match
what the RDFa spec currently requires, and which I think should be added
to the test suite:

1) Comment in node creates XMLLiteral. (Applies to both XHTML and HTML.)

   xmlns:ex="http://example.org/"
<head>
   <title>Test NNNN</title>
</head>
<body>
   <p property="ex:test">test <!-- example --> test</p>
</body>

ASK WHERE {
   <$TCPATH/NNNN.html> <http://example.org/test> "test <!-- example -->
test"^^<http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral>.
}

========

2) Processing instruction in node creates XMLLiteral. (Applies only to
XHTML.)

   xmlns:ex="http://example.org/"
<head>
   <title>Test NNNN</title>
</head>
<body>
   <p property="ex:test">test <?example?> test</p>
</body>

ASK WHERE {
   <$TCPATH/NNNN.html> <http://example.org/test> "test <?example?>
test"^^<http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral>.
}

========

3) CDATA in node does not create XMLLiteral. (Applies only to XHTML.)

   xmlns:ex="http://example.org/"
<head>
   <title>Test NNNN</title>
</head>
<body>
   <p property="ex:test">test <![CDATA[example]]> test</p>
</body>

ASK WHERE {
   <$TCPATH/NNNN.html> <http://example.org/test> "test example test".
}

========

Current implementations give at least three different answers to the
first test case, and at least two to the second. (I've not seen any do
anything unexpected on the third, but I saw no other test case that uses
CDATA so it seems worth having one.)

--
Philip Taylor
[hidden email]