SAZ - Discussing use cases for EARL following on from email thread
SAZ - Do those use cases make the potential of EARL visible
SAZ - can we start with these, or is there anything missing?
CMN - Good start, but maybe something missing - we'll realise then.
SAZ - no big holes, business case too, what EARL does better
Should we have Persona style use cases, should expand it.
CMN - I'm not sure how far it's worthwhile going down this route, useful when doing EARL is cool.
CMN - We doing technical work, persona stuff is more for non-tech does the EO group understand our stuff?
CMN - I want to Focus on the technical needs.
CMN - Does it meet the requirements rather than the use cases being clear.
SAZ - We need to write a good primer as part of deliverables.
CMN - we can leave that to later.
zakim who's making noise?
CR - we can delay
<chaalsMEL> CR, JJ: we can write the real primer later - we have enough to go on for now
JL - Agrees to.
CMN - 1 possibility is if we're writing 2 specs, JK can continue and we develop in paralell.
CMN - much of it is editorial and uncontroversial.
CMN - Technical detail takes more focus
SAZ - we can take stuff to EO as we get good documents rather than just publishing everything at the end in a big bang.
CMN - we can keep collecting examples as we go rather than having to scrabble around at the end.
SAZ - we can wait until we start publishing so renew looking at it in the near future.
SAZ - 2 table of contents coming soon.
cheers
<shadi> http://lists.w3.org/Archives/Public/public-wai-ert/2005Apr/0001.html
SAZ - Processing model of EARL - do we want to expand on this now?
SAZ - A tool wants to express results of a test it's just done
SAZ - How does it do that?
SAZ - What is it I'm testing?
SAZ - What is the test?
SAZ - Depending on the type of test, we need several pointers to point to the thing we're testing
SAZ - See Chaals example of client side image maps.
<JohannesK> http://lists.w3.org/Archives/Public/public-wai-ert/2005Apr/0047.html
SAZ - The thing we're testing defines the nature of the EARL we produce.
<chaalsMEL> http://lists.w3.org/Archives/Public/public-wai-ert/2005Apr/0047.html - johannes' idea about how to keep it simple...
SAZ - Collect ideas of the sort of EARL structures we'll make
<Zakim> chaalsMEL, you wanted to add "what did the test" to the second list, and suggest that the lists can movecloser together
SAZ - The other thing that has the big impact is the Type of Entity that performed the test.
CMN! - The other thing that has the big impact is the Type of Entity that performed the test.
CMN - Is there anything missing?
<chaalsMEL> JL Don't think anything obvious is missing
SAZ - XPointer / XPath type things...
SAZ - should use XPath so we can point to multiple things.
SAZ - XPath doesn't say what should happen with a non WF doc.
SAZ - We can't rely on how a parser might do something.
SAZ - it's harsh if we don't have any other way to do
<Zakim> chaalsMEL, you wanted to suggest that Xpath is only sometimes the thing we want
CMN - Where we have a spec that says it's undefined outside a particular range.
CMN - XPath is only sometimes the thing we want to use.
CMN - Locating properties should be seperate, because we can use different things on different tests.
CMN - we can find something that works at different times.
CMN - We'll often want to put a handful in.
CMN - so we can hope to get close even if the document has changed.
CMN - we can't guarantee robustness, but as much as we can is good
SAZ - now convinced that seperating location/subject is a good thing.
SAZ - URL doesn't make much sense for web content as a locator...
SAZ - XPath,
JK - line/col is an option.
<chaalsMEL> JL - itis useful to have as a possibility, but it is not always robust enough
<chaalsMEL> JL - we realy want as many thing as we can have.
<chaalsMEL> JL - if there are enough things we can thinkn of and define, that is better
<Zakim> chaalsMEL, you wanted to say tests over a website (such as usability of navigation) will use a page's URI as locatio for individual parts of a collection.
CMN - if we test a website, seperate term between websites and collection
CMN so a test subject of a site could have a location of a uri.
CMN - SSI includes could also mean that there's a URI for a part of page
CMN - All information is useful
CMN - an element name and attribute can be good but sometimes redundant to XPath
CMN - a large list of useful things, will they be straightforward and how can we put them together?
CMN - Need to implement and see how it goes
JK - need to not get too hung up on testing mark-up documents
JK - also need to test JS and CSS documents
<chaalsMEL> [Good point Johannes. +1]
JK - line/col is more particular here.
SAZ - break down web-content between mark-up and non-mark-up, we're investing a lot of time in mark-up side of things
SAZ - How do I describe a location for well-formed XML as one thing has one set of techniques for locating errors.
SAZ - different methods have different methods for locating the errors.
SAZ - the type of errors are likely to be very different between the different types so the type of locators may also need to be different.
<Zakim> chaalsMEL, you wanted to say if we think we can get the well-formed XML case pegged with xpath and some robustness stuff, like context hashes, we can start looking at other types
CMN - well formed XML well defined, css and JS are crucial for WCAG use cases.
CMN - Is there Fuzzy Pointers written up?
<chaalsMEL> ACTION: Jim to get documentation of fuzzy pointers [recorded in http://www.w3.org/2005/04/05-er-minutes.html#action01]
JL - Not yet, I'll take an action item
SAZ - What if we launch with well-formed, css and JS and then along comes PDF or flash or something, how do we point to these? Should we move this outside the spec so as to not have to define everything!
CMN - how do we limit the number that developers have to implement, rather than forcing everyone to develop everything.
CMN - need to define a subset for developers of e.g. webcontent that people should be developing regardless, but people are free to develop other better stuff!
CMN - which might become required in the future
CMN - can still include extra ones beyond the standard for more robust locating
SAZ - I only see URI, line and XPath now, looking forward to more ideas.
SAZ - we need to describe these for different types of docs and encourage people to develop as many as a time
CMN - what is a minimally conformant EARL doc?
CMN - we expect a date? we might also expect ...
SAZ - Not everything is pointable, always need a subject
CMN - we could say anythign that wants to be EARL conformant must be able to know what to do with various types and if appropriate create the types.
SAZ - CR has a tool that can create EARL from the WCAG test-suite, create a reference EARL??
CR - That's exactly what it's there for, to create good EARL, we're not there yet, should have some good examples soon.
SAZ - we also need to create bad EARL examples???
CMN - I'm not sure how much we need to do beyond not breaking RDF
CMN - Important thing is to collect examples and make sure they are good EARL
SAZ - make sure the RDF is valid with the RDF validator
sorry chaalsMEL , I missed that one
CR - Is anyone looking after the Schema?
CMN - I've offered
CMN - people need to ensure I do it
SAZ - The schema will pretty much be the spec, with just annotations.
<chaalsMEL> http://www.w3.org/RDF/Validator - the RDF validator. Put allyour examples in it and make sure that at least they are valid RDF.
SAZ - Meetings may get cancelled due to lots of travelling next couple of weeks.
<chaalsMEL> ... you can also use it to show what the RDF means, so you can do some reality checking of whether your document makes sense.
SAZ - I'll provide table of contents for spec and primer
SAZ - like to have something publishable by the end of may.
SAZ - we should capture the current work and get something published.
SAZ - I think that's enough.