Re: Conformance tool specification

Charles,

Your notes say that

 > For each element there can be tests that are automatic, or manual.

What did you have in mind for assertions that involved multiple elements, 
especially non-contiguous elements?  For example, if there's a server side 
image map there should be equivalent text links, but they don't have to be 
next to the image map (e.g. they may be at the bottom of the page).  I 
guess you'd write an assertion that included all the elements and if any 
one of them changed the assertion would be withdrawn?

Another case: when tables are used for layout, the document must make sense 
when linearized. Similarly, if CSS positioning is used, the elements must 
make sense when read in the order they appear in the HTML.   In this case 
you'd have to withdraw the assertion if any of the elements changed, or 
their order changed, or anything was inserted in their sequence, or 
positioned into their bounding box, right?

Hmmm.  When tables are used for layout you could simply write the assertion 
against the whole table.  But you'd still need to reference individual 
elements when CSS positioning is used.

Len

At 04:07 AM 9/19/00 -0400, Charles McCathieNevile wrote:
>There is a canonical XML spec that could be used. And IDs are better than
>checksums, since you can find them faster - comparing checksums element by
>element isn't as good, just possible and saves human time. But  of course the
>ids can also be changed (fragment identifiers aren't part of the URI in the
>http transaction at the moment...)
>
>Charles
>
>On Mon, 18 Sep 2000, Leonard R. Kasday wrote:
>
>   And if someone simply re-arranged the elements you could still find the
>   originals... and without using id's, since you've got a hash of the 
> checksums.
>
>   Yes. Neat.
>
>   Only suggestion is would be to cannonicalize whitespace before doing
>   checksums.  E.g. replace all white space with exactly one space and omit
>   whitespace between > and <  .
>
>   Len
>
>
>   Yes, I realised that. The value of doing it over elements specified by
>   xpointers is that you can also have a checksum for the particular elements,
>   so you can figure out which of those are different, break the document down
>   and up again keeping as much as is still fine.
>
>   Cheers
>
>   Charles
>
>   On Mon, 18 Sep 2000, Leonard R. Kasday wrote:
>
>      Good approach... at least for fixed web pages, or for reporting on the
>      status of a page at a particular time
>
>      Problem comes in if page has changed.  You do spot that via the hash 
> (or do
>      you mean checksum?).
>
>      But if a page does change, it would be useful to retain as much 
> information
>      as possible, not just say that the RDF no longer applies.  One way to do
>      this is to make sure all elements have unique id's that do not get
>      changed.   Or, if a checkpoint refers to a regions of a page, with many
>      elements, that section should be wrapped in a <span> with a unique id.
>
>      Still have a problem if regions overlap instead of being nested.... 
> hmmm...
>      can  xpointer specify regions between two elements?
>
>      Len
>
>
>      At 11:19 AM 9/18/00 -0400, Charles McCathieNevile wrote:
>      >I wrote some very rough notes on how one could work.
>      >
>      >I am sending this mostly at this stage so the page doesn't get lost 
> <grin/>
>      >
>      >http://www.w3.org/2000/09/conf-tool
>      >
>      >charles
>      >
>      >--
>      >Charles McCathieNevile    mailto:charles@w3.org    phone: +61 (0) 409
>   134 136
>      >W3C Web Accessibility 
> Initiative                      http://www.w3.org/WAI
>      >Location: I-cubed, 110 Victoria Street, Carlton VIC 3053, Australia
>      >September - November 2000:
>      >W3C INRIA, 2004 Route des Lucioles, BP 93, 06902 Sophia Antipolis 
> Cedex,
>      >France
>
>      --
>      Leonard R. Kasday, Ph.D.
>      Institute on Disabilities/UAP and Dept. of Electrical Engineering at 
> Temple
>      University
>      (215) 204-2247 (voice)                 (800) 750-7428 (TTY)
>      http://astro.temple.edu/~kasday         mailto:kasday@acm.org
>
>      Chair, W3C Web Accessibility Initiative Evaluation and Repair Tools 
> Group
>      http://www.w3.org/WAI/ER/IG/
>
>      The WAVE web page accessibility evaluation assistant:
>      http://www.temple.edu/inst_disabilities/piat/wave/
>
>
>   --
>   Charles McCathieNevile    mailto:charles@w3.org    phone: +61 (0) 409 
> 134 136
>   W3C Web Accessibility Initiative                      http://www.w3.org/WAI
>   Location: I-cubed, 110 Victoria Street, Carlton VIC 3053, Australia
>   September - November 2000:
>   W3C INRIA, 2004 Route des Lucioles, BP 93, 06902 Sophia Antipolis 
> Cedex, France
>   --
>   Leonard R. Kasday, Ph.D.
>   Institute on Disabilities/UAP and Dept. of Electrical Engineering at 
> Temple
>   University
>   (215) 204-2247 (voice)                 (800) 750-7428 (TTY)
>   http://astro.temple.edu/~kasday         mailto:kasday@acm.org
>
>   Chair, W3C Web Accessibility Initiative Evaluation and Repair Tools Group
>   http://www.w3.org/WAI/ER/IG/
>
>   The WAVE web page accessibility evaluation assistant:
>   http://www.temple.edu/inst_disabilities/piat/wave/
>
>
>--
>Charles McCathieNevile    mailto:charles@w3.org    phone: +61 (0) 409 134 136
>W3C Web Accessibility Initiative                      http://www.w3.org/WAI
>Location: I-cubed, 110 Victoria Street, Carlton VIC 3053, Australia
>September - November 2000:
>W3C INRIA, 2004 Route des Lucioles, BP 93, 06902 Sophia Antipolis Cedex, 
>France

--
Leonard R. Kasday, Ph.D.
Institute on Disabilities/UAP and Dept. of Electrical Engineering at Temple 
University
(215) 204-2247 (voice)                 (800) 750-7428 (TTY)
http://astro.temple.edu/~kasday         mailto:kasday@acm.org

Chair, W3C Web Accessibility Initiative Evaluation and Repair Tools Group
http://www.w3.org/WAI/ER/IG/

The WAVE web page accessibility evaluation assistant: 
http://www.temple.edu/inst_disabilities/piat/wave/

Received on Tuesday, 19 September 2000 09:21:59 UTC