Comment to Pointer Methods in RDF 1.0

Dear all,

As a followup of my messages of Jan 22
<http://lists.w3.org/Archives/Public/public-wai-ert/2013Jan/0003.html> and
Apr 3 <http://lists.w3.org/Archives/Public/public-wai-ert/2013Apr/0002.html>
, I am providing some further background info for the next update of Pointer
Methods in RDF 1.0.

I understand internal comments for that document are no explicitly expected
at this moment; but in that case, the suggestions can be anyway available
for archival, and be later revisited. I also understand that, although a new
WD was planned in the charter for this quarter, it may not be possible to
achieve that goal in time. We at UPM are in any case interested on this
draft progressing and keeping pace to the advancements taking place
elsewhere.

My comment is related to the following use case: suppose I would like to
assert that a specific part of a web application in a specific state does
not conform to some accessibility criteria. Of course, the application (as a
whole) does not conform, but I would like to signal the offending part. How
do I do it? That is, how do I point to the specific state of the web
application where the non-conformance is happening?

Pointers in RDF does not currently support that use case. Nonetheless, this
has been considered among the usual evaluation scenarios by other (draft)
documents. AERT (draft) considers "dynamic content" as one of the test
subjects potentially evaluated by tools and "web testing APIs" as one of the
ways to customize tests. Tools which test that dynamic content "must emulate
different user actions (...) that modify the status of the current page or
load new resources"  WCAG-EM (draft) makes explicit provisions for web
applications as particular types of web sites.  The states of these web
applications "may not have unique URIs and may need to be identified by
describing the settings, input, and actions required to generate them".

Different technologies already exist that allow identifying the states of a
web application, or more generally, the test fixture to be applied when the
evaluation is performed.

- WebDriver API [1] (Working Draft) allows writing tests that automate a
browser. It is based on Selenium WebDriver [2], an open-source product which
can run those kinds of tests. Basically, the idea is that test scripts can
be described in a computer-readable format, which can in turn be
automatically run, as long as the user actions can be emulated (e.g.
invoking the same API that would listen to user input events). In our
context, we do not need web application pointers to be automatically
evaluated by a computer (although that may be a desirable property), but
just to identify the specific web application state (and part). Note that
WebDriver uses some of the same technologies considered by Pointers in RDF
(e.g. XPath, XPointer).

- Hashbang URI fragments [3] use an otherwise-non-legal URI fragment, which
starts with the character sequence #! ("hash, bang") to capture relevant
AJAX state. As this is an unexpected, unsanctioned, and invalid use of URI
fragments, discussions have been raised about its suitability. Fortunately,
some solutions have been proposed by private companies [4], and W3C TAG [5]
to lessen their disruptive impact while retaining its usefulness.

- A restricted subset of the cases covered by WebDriver could be specified
by a sequence of HTTP requests, which can be represented using HTTP
Vocabulary in RDF (draft) [6]. However, they might not capture complex user
interactions, or would difficultly adapt to shifting responses which
dynamically determine the contents of the next request. Moreover, neither
HTTP in RDF nor EARL define how that sequence of requests must be
represented (an rdf:List?).

WebDriver (as well as HTTP in RDF) follows an "white-box" approach for
defining the state of a web application: a state is just defined by
specifying a set of stimuli. Hashbang URI fragments, in contrast, follow a
"black-box" approach: a state is defined by its application-specific
identifier.

Some other comments on other, unrelated use cases:
- RFC5147 [7] should be taken into consideration for pointers within textual
resources. They might be completely covered by the current version of
Pointers in RDF, yet it might deserve a look and, in any case, a reference
to ensure document evolution keeps aligned.
- Flash tag attributes [8] may be taken into consideration to specify the
state and parameters of Flash movies. They can be passed through URLs, but a
URL may not always be available. It should be investigated how, which and
whether these parameters should be used, as maybe they are not exactly
pointers but "configurations".

Regards,

Samuel.

[1] http://docs.seleniumhq.org/docs/03_webdriver.jsp
[2] http://docs.seleniumhq.org/docs/03_webdriver.jsp
[3] http://www.w3.org/blog/2011/05/hash-uris/ 
[4] http://www.w3.org/2001/tag/2011/02/HashInURI-20110228.html
[5] https://developers.google.com/webmasters/ajax-crawling/
[6] http://www.w3.org/TR/Pointers-in-RDF10/
[7] http://tools.ietf.org/html/rfc5147
[8] http://helpx.adobe.com/flash/kb/flash-object-embed-tag-attributes.html

Received on Thursday, 28 November 2013 17:59:52 UTC