Locating the subject and dynamic content

Hello all,

I'd like to clarify my opinion (that in deed is the TAW Team opinion) about locating the subject and dynamic content.

When I said that the big one problem is the dynamic content, which is actually most of the web content, I am thinking about the "real" location of the problem not about content that changes dynamically, so the problem I'm talking about is not the persistence of the content but the "origin" of the problem. 

The best reason I imagine to have a location or reference to the problem is to use it for some repair actions, but with the proposed solutions we are offering an "imaginary" location of the problem which is almost useless for this objective. 

For example:

Imagine that finally we found a properly way to locate the test subject, fuzzy pointers, xpointers or whatever, that looks like a good solution for everybody. The problem is that you are locating something that is not the "real" problem, you are locating the problem at a web page which is served by a server, but the "real" problem is located anywhere inside a huge amount of ASP, JSP or whateverSP you use, databases, etc.

A good simple dynamic example could be the images rotator attached (a way to see an image in a page that is different every time you reload the page). There are three files:

 Images.ini --> a configuration file that includes src, title, and alt attributes  
 Index.php --> the web page that includes the rotator  
 Rotator.php --> the php code needed to make the rotator effect

When you have the rotator in action (the index.php served) you have an xhtml page which shows a different image each time. If there were no alt text for the image you have an accessibility problem that you could locate in the served page, but if order to repair this problem, are you going to repair this served page?


Well, on every TAW release we have made ourselves the same question "What could be this (a location to the problem in the served page) useful for?" and we think that is only useful for educational purposes, or as a help for seeing the problem in its context.

So, in my opinion again, there are two dynamic content related problems:

- Monitoring a Web site over time (This is the 5th scenario at the Johannes document [1]) In this scenario dynamic content is a problem, and some kind of persistent location to the problem could be useful.

- Fixing problems
In this case, a reference to the problem at the web page is not valid because if you want to fix the problem, you will need to fix the JSP, ASP or whatever, which is the "real source" of the problem.


My conclusion is, is really necessary to add a complex pointer to the subject of a problem to the specification? Or maybe a simple pointer, like line numbers, could be enough.

I think that we need to think about this question before continuing the locating discussion, specially because in the last teleconference Shadi talked about some reflections on EARL from CSUN [2] and one of them is that tool developers are not yet convinced of using EARL, and I think one reason is that EARL is RDF, a not well know technology that seems complex, and if we add more unnecessary complexity to the specification, with xpointer, fuzzy pointers or so on, it could be a barrier for the wide use of EARL.

[1] [http://lists.w3.org/Archives/Public/public-wai-ert/2005Mar/0048.html]
[2] [http://www.w3.org/2005/03/22-er-minutes.html#item01]

Sorry for the big message, I'm waiting for your opinions.

Carlos.

 
--------------------------------------

Carlos Iglesias Moro

Fundación CTIC
Parque Científico-Tecnológico de Gijón
33203 - Gijón, Asturias, España

teléfono: +34 984291212
fax: +34 984390612
email: carlos.iglesias@fundacionctic.org
URL: http://www.fundacionctic.org