Re: Locating the subject and dynamic content

On Wed, 23 Mar 2005 22:41:13 +1100, Carlos Iglesias  
<> wrote:

> 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.
> 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.

Well, in monitoring a site for accessibility, just knowng that there is a  
problem in a rendered page is useful. After all, this is what has an  
impact on users of the site, who don't see the process of putting together  
the page. And it can act as one factor in developing a sensible process  
for repair - especially in the kind of large site that is substantially  
generated "dynamically", because it helps to determine whether the problem  
actualy arises for 0.1% of users, or for 50%...

> - 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.

Yep. I think the basic answer for this is for a system that puts pages  
together to have some way of describing how the pages are put together. In  
other words, noting what are the sources inside the publishing system for  
the ifferent parts of a page that is outut. What end users test or have  
problems with is usually output - certainly usability testing is going to  
be done primarily on output pages not on the internal system, and many  
legal compliance tests will likewise only apply to the generated content

> 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 have yet to see a system based on line numbers that is robust over any  
but the most trivial kind of repairs. In other words, it is fine if you  
have an enclosed system, and you do one chec followed by one repair. But  
if you have several tools runing together, or if you do a group of repairs  
at once, you invalidate the line numbers much too fast.

In general, line numbers are not all that reliable even just in opening  
the source code in a few different tools. Whichis perfectly aceptable for  

I agree that we should not look for a solution any more complex than we  
need. But as far as I can tell, line numbers are almost always useless in  
an open system - and there is no real need for a standardised reporting  
language in a closed system.

> [1]  
> []



Charles McCathieNevile                      Fundacion Sidar   +61 409 134 136

Received on Sunday, 3 April 2005 04:20:51 UTC