Re: Agenda for Monday and Tuesday

Wendy A Chisholm wrote:
> 
> Hello,
> 
> Based on the feedback I have received from people, I've added to the 
> agenda [1] a list of topics to discuss on Monday and Tuesday.  I've 
> included links to references for most of the topics.
> 
> Please let me know if there is a topic you would like to add.
> 
> There's a lot here, so we'll have to prioritize which to cover.  I would 
> like to start with the specification since we're aiming to publish 
> something to TR in early July.
> 
> Best,
> --wendy
> 
> [1] http://www.w3.org/2002/05/er-swade-f2f#Agenda
> 

Two things about EARL that I would like to be handled before it
becomes a recommendation.

And then a number of smaller issues wrt the document
http://www.w3.org/WAI/ER/2002/06/21-earl1.html.

    Giorgio


1. problem location

    EARL needs to cover also the representation of the location in the
    page which the EARL statement refers to. Possible location
    representations are:
    - line number (in source file)
    - character offsets
    - DOM node index (like 3rd IMG element)
    - fuzzy xpointers
    - ...

    The rationale behind this requirement is that interoperability of
    EARL is based on this. Otherwise there is no way in which
    tool A produces EARL to be used by tool B (where A and B are
    evaluation tools, authoring tools, ...). "Used" may mean several
    things, like 'do fixing', 'do differential reports', ...

    The real difficulty lies in the fact that this location
    representation has to be:

    - robust wrt document changes: for example line number is not
      tolerant of edits that occur in any previous line; DOM node index
      is not tolerant of edits that add/remove nodes with same tag and
      smaller index; ...
    - robust wrt different tools: starting from same document, tool A
      may produce a certain line number for a problem, tool B may
      produce a line number that is slightly different (because they
      use different HTML parsers that may add/remove elements at will:
      try with mozilla, dreamweaver, frontpage and you see!)

    Since developing such location representation may be challenging, I
    suggest that in EARL we include:
    - the ability to specify one or more problem locations (eg. line
      number, node index, ....)
    - EARL specification should say explicitly what is the meaning of
      these locations, so that tool builders can try to normalize the
      representations that their tools produce.

2. tool for comparison of EARL reports

    My concern is why should our customers pay for having EARL included
    in tools like LIFT. What is their benefit?

    I think that a good answer is to be able to add EARL reports
    produced by tool A into a service that is capable of integrate them
    and then query them so that the user can:

    - compare reports produced by tool A and tool B on resource C
    - integrate reports by tools A1,A2,... and produce a report of all
      the findings ...
    - compare reports produced by tool A on resource C today and 1 week
      ago
    - (any of the scenarios described in the
      http://www.w3.org/WAI/ER/2002/06/21-earl1.html document)

    I think W3C should develop a proof of concept of such a system. For
    two reasons:

    - it would fit in the suite of validator tools
    - end users would come to w3c to do that sort of integration of
      reports and they would assume the integration/comparison to be
      rather neutral. I'm not convinced that is a particular vendor
      implements it, users would trust it to make neutral comparisons.


Minor things concerning the document
http://www.w3.org/WAI/ER/2002/06/21-earl1.html.

* ConfidenceLevel:
   how is one going to decide what is certain, likely, unlikely? what
   is the meaning of these terms? If EARL is to be used for comparison,
   then this should be defined.

* TestMode:
   what is the meaning of the 3 words auto, heuristic, manual?

* ResultProperty
   again, meaning of the 6 terms?

Received on Monday, 24 June 2002 04:14:56 UTC