W3C home > Mailing lists > Public > public-earl10-comments@w3.org > May 2011

Bug 037: Meeting F03

From: Sean B. Palmer <sean@miscoranda.com>
Date: Thu, 12 May 2011 13:16:34 +0100
Message-ID: <BANLkTikqCbqrf3WqGdqPLyqgj8XNKmnCnw@mail.gmail.com>
To: public-earl10-comments@w3.org
This is feedback on the following Last Call Working Drafts:

Representing Content in RDF 1.0
W3C Editors Draft 2 May 2011
http://www.w3.org/WAI/ER/Content/WD-Content-in-RDF10-20110502

Pointer Methods in RDF 1.0
W3C Editors Draft 27 April 2011
http://www.w3.org/WAI/ER/Pointers/WD-Pointers-in-RDF-20110427

Specifically that they don't meet their requirement F03 here:

http://www.w3.org/WAI/ER/EARL10/WD-EARL10-Requirements-20090526#features

It is not clear whether this is even a requirement, on which compare Bug 035.

Assuming that it is, these Working Drafts don't meet it. Take for
example this section:

—
Situation F: Document Object Model (DOM) changed in memory

Given a DOM Document in memory, originally created by parsing some XML
source, but afterwards changed by DOM operations. A cnt:XMLDecl
resource may be created from the information in the Document node
itself (version, declaredEncoding and standalone), and a
cnt:DoctypeDecl resource from the information in the DocumentType
node. A cnt:ContentAsXML resource may be created after serializing the
relevant child nodes of the Document node to create object literals
for cnt:leadingMisc (serialize Comment and ProcessingInstruction nodes
preceding a DocumentType node) and cnt:rest (serialize nodes following
a DocumentType node). See the Mapping between the Document Object
Model (DOM) and Content-in-RDF properties.
—

>From Representing Content in RDF 1.0, § 5 [i.e. 4, compare Bug 036]
Usage scenarios:

http://www.w3.org/WAI/ER/Content/WD-Content-in-RDF10-20110502#scenarios

The requirement is “F03 / EARL 1.0 should support persistency of the
validity of the results with respect to modifications or variations of
the subject due to its dynamic nature where applicable.” If you're
capturing results from a dynamically changed document, you need to
provide context about those changes. Situation F doesn't talk about
the context, only about the result after the change has happened.

This is a simplistic view of how content works, because a page isn't
just its DOM, but also the programmatical structures attached to the
DOM. For example, say that I change all values of */@id in a document
so that they have "_" appended. Then I write some code to make sure
that when the document.hash changes, this is still correlated with
these changed IDs. Why would somebody want to do stuff like this? Well
this is from a production system that I wrote recently in fact, people
have to do all sorts of crazy things these days. But in Situation F,
this is not accounted for, because it can only capture the state of
the document with the changed IDs, but it cannot capture the fact that
the document.hash IDs are mapped onto the changed IDs. If you're
trying to evaluate whether this system is accessible, the current
Content-in-RDF draft doesn't give you anything to help with that.

It's a similar sort of case for Pointers-in-RDF. To take the same
example, do I now point to an element whose ID is "example", or
"example_"? In the DOM it's "example_", now, but in the interface the
accessor is still "example". There's no way to say in the pointer spec
that this kind of dynamicism is going on, so anybody trying to
interpret the results is probably going to be very confused. Imagine
that the EARL Schema report says the page evaluated is /path#example,
but then the pointer is id('#example_'). Not as great an example for
the pointer spec, but you can imagine what's going to happen if
there's a lot of dynamicism that depends on complex user interaction
in a document. The changes between the states will be as important as
the individual states themselves.

So these documents need to reflect much more carefully how the web
works in practice these days. Though CR is the implementation phase,
it's a good idea to try to build test models of what you're working on
even at the WD stage because planning something out on paper is very
different to actually building the system and seeing what works and
what needs to be changed. Even without implementing such a model, it's
easy to discern problems such as the above, but it may be just one of
a class of problem, not an isolated single feature that needs to be
accommodated for.

This is a very substantial bug.

-- 
Sean B. Palmer, http://inamidst.com/sbp/
Received on Thursday, 12 May 2011 12:17:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:42:24 UTC