Re: Locating the subject and dynamic content

Hi Carlos,

Interesting approach! I've also struggled with the thought about the
"real" origin, especially for client-side scripting. Often the cause of
the problem (root) is far away from the impact area and we need to keep
that in mind.

However, I think line numbers are simple but broken in many aspects.
Alone the fact that they may be different according to the operating
system or editor etc makes them very weak.

Also, it is only when we can provide more sophistication (added value)
that EARL will become more attractive for tool developers. If we only
provide line numbers and plain text which could be easily formulated in
comma separated files then there is even less incentive for tool
developers to implement it. If we provide features that allow them to
easily query for more information (e.g. change over time, etc.) then the
adoption of EARL may be more beneficial.

To clarify, let's take your example with the image rotator. Let's assume
that this rotator is used on several pages throughout a Web site. Let's
also say that the Web site has been evaluated and all the test results
are stored in a repository somewhere.

If you could now query the repository for a pattern (for example the
XPath expression of the error location), you would get back a whole set
of pages that have this same problem. As a developer you could more
easily see that this problem is probably coming from a template or
program. Line numbers alone would not give you this information.

Regards,
  Shadi


-----Original Message-----
From: public-wai-ert-request@w3.org On Behalf Of Carlos Iglesias
Sent: Wednesday, March 23, 2005 12:41
To: public-wai-ert@w3.org
Subject: 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

Received on Wednesday, 23 March 2005 13:43:34 UTC