EARL and locating a problem...

Hi folks,

during the meeting we discussed the question of whether earl should provide a
pointer to where it finds a specific problem within a page, or whether it is
better to write earl statements about objects within a page, and then
describe the page as a collection of objects that do or don't meet a given
set of requirements. I took an action item to carry the discussion on outside
the meeting.

I used to believe the latter, so I will try to explain why I have moved to
the former...

Part of this has been pragmatically motivated by talking to developers of
repair tools. In order to do repairs it is important to know where the repair
should be made, if possible. Both approaches work, up to here, but from this
point it becomes tricky.

As I see it, the problem is not that we need to know what needs retesting
afterwards. That is more or less the same problem in both methods. Details of
whether changing a particular item, or repairing a fault, can be expected to
have or not have an effect on other related requirements is probably beyond
the scope of EARL and lives in the land of testing processes.

But details of what a page contains need to be provided,and need to be exact,
if we are not going to have a location pointer for a particular result that
is independent of the test object (which may or may not have a larger scope).
This requires us to be able to specify exactly what a page consists of, and
we may have to divide it along several different axes for different types of
tests. That strikes me as a lot of work that only sometimes pays off.

Moreover, it isn't necessary to define that as a method of locating problems
in order to use it. The place where it strikes me as a valuable technique is
in assessing databases behind content management systems. But even there, it
seems like a messy way to deal with problems in the template used to produce
an instance of content for rendering to the user. It is something that can
always be done, but there seem like good reasons for using what is
essentially the shortcut of allowing a relevantLocation or something similar
to be a property of a result.

An interesting paralell is Annotea. It is possible to annotate something
directly even if it is only a part of a larger document, but the annotea
design instead annotates a whole document and provides a location as the
information about what exactly was located. It might be interesting to know
if this was a deliberate design decision, and why.

cheers

Chaals

Received on Thursday, 27 June 2002 21:49:13 UTC