[techs] summary of today's techniques telecon

issue: should we have a css (for example) document that stands on its own? 
if we have checklists where every item must be met for conformance, then 
techniques documents should take a similar form. In other words, since CSS 
can not be used alone to meet all of the success criteria it should not 
exist as a separate document.  It is fine for it to exist as a separate 
source file but should not be used to generate a separate document.

discussion:
- if a person working on the css part of their work, they are likely to 
want a css-specific document.
-  are techniques documents means to conformance (like checklist)?
- we can generate a checklist easy enough that will incorporate the various 
technologies that someone is using, but will we be generating entire 
techniques documents?
- would we end up with one long techniques document that contains 
everything?  technologies are intended to be used together.

propose: log this issue in the requirements document. attempt to move on to 
get techniques requirements published.  won't know the answer until we get 
further along.

action mc: log this as an issue in the techniques requirements

===
schema and templates

richard gave an overview of work on i18n templates.
he hopes to develop a variety of templates for a variety of audiences. 
create a shell to pull in info as needed.

issue: create a template for every possible output? e.g., a template for 
html+css and another for svg+script.  then someone says, "i want 
svg+html+css" how would they get that?

discussion:
- they would have to create it. or  perhaps write an xsl specific to that 
document. to create these views, create an xml file with structure and xsl 
to extract the info at which point.
- templates vs dynamic generation. i18n also planning for dynamic 
generation? not now b/c of complexity needed to generate 
dynamically.  relationships defined in template not in database.

propose (for wcag): use templates for short-term since relationships in 
database will be complex.  use work on templates to help define what 
relationships need to be defined in database and how to define them.

===
editing process possibility:
1. attach editors to different source documents
2. submission process (form to generate xml and send to editors), editors 
add to source
then multi-people not editing same thing at same time.

===
action: wac work on schema and tools (talk w/altova re: xmlspy authentic 
view of xmlspec+richard's extensions??)
action: bc continue work on the checklist (prototype).
action: mc revise techniques requirements
action: mc and bf to review html techniques and begin submitting proposals 
to the list (for changes in content)
action: all discuss new phrase to replace "rules" on thread on w3c-wai-gl
action: mc look at templates

===
tomorrow: some of this will come up at tomorrow's wcag telecon

next week: report back on action items and discuss schema
milestone: next week we'll start to put in place for creating a document 
(although likely to be somewhat underway based on current action items)

-- 
wendy a chisholm
world wide web consortium
web accessibility initiative
http://www.w3.org/WAI/
/--

Received on Wednesday, 29 January 2003 11:34:58 UTC