W3C home > Mailing lists > Public > www-qa@w3.org > November 2001

Re: [www-qa] Re: input document for f2f

From: Lofton Henderson <lofton@rockynet.com>
Date: Fri, 09 Nov 2001 10:13:08 -0700
Message-Id: <4.3.2.7.2.20011109093631.02ccf140@terminal.rockynet.com>
To: David_Marston@lotus.com
Cc: www-qa@w3.org
I'll add a couple of comments to Daniel's reply...

At 04:42 PM 11/7/01 -0500, David_Marston@lotus.com wrote:

>A few quick reactions:
>People could take away different interpretations depending on what they
>think you mean by "interoperability" -- is it the ability to plug in any
>vendor's implementation of a single Rec within a possibly proprietary
>software framework, or is it the ability to plug together different
>vendors' implementations of W3C Recs A and B?

I see at least three definitions:

1. ability to swap like components, for single Rec, from different vendors 
(e.g., two different SVG-viewer plug-ins).
2. ability to plug together different components, for single Rec, from 
different vendors (e.g., a WebCGM generator and a WebCGM viewer/plug-in)
3. your last option, "the ability to plug together different vendors' 
implementations of W3C Recs A and B".

I'm not sure if you meant to encompass #1 and #2 in your first option.

In any case, I agree that we should define it more carefully, and be clear 
about which flavors we're targeting when we discuss it in the Charters, 
Framework and elsewhere.


>In part 3.1, you should mention use of the test suite by a third-party
>test lab, which may be a (real or virtual) magazine doing testing for
>publication, or it could be an advisory service acting on behalf of
>paying clients. Also say something to position the idea of testing across
>multiple Recommendations, possibly from multiple WGs. This is needed for
>certain kinds of software but may be wishful at this time, so I'd say
>that the notion should be acknowledged but positioned as a long-range
>objective. Some of the goals in 1.1 around common test tools would be
>more compelling if they could be used to test the interoperation of
>multiple Recs.
>
>The mention of Accessibility and Internationalization (A&I) in 3.3.10
>raises an interesting coordination issue. Then in 3.4, another aspect of
>coordination arises, which actually interacts: do the A&I groups work
>with QA as well as the Rec-track WG, does QA try to represent A&I
>interests, does QA join the list (that A&I are currently on) of groups
>that review the work of Rec-track WGs, or is there some other
>relationship?

Daniel answered this, but I'd add:  in addition to considerations of a 
"horizontal domain", which would take some time to sort out and organize, 
there are the immediate issues which you point out, before a Framework 
document can be finished.  For example., do we "represent A&I interests" 
with statements such as, "Test materials which consist of content (HTML, 
SVG, XSL, etc) shall conform to applicable WAI standards).

(It's probably time for us to start an issues-tracking document.)

>Also, who gets to have their say about the Requirements
>Document of a Rec-track WG? While answering these questions, we must not
>foster the thought that quality is applied by an external force after
>the WG creates a draft or CR; the WG itself is responsible for doing
>their work under the guidance of this Framework and other statements
>about quality.

I think this is clearly stated in the QA Activity Statement and the 
Charters, but it is worthwhile highlighting it in the Framework document.


>To answer your question in Chapter 5, I think there *would* be an
>expectation resembling Conformance, but it probably emerges better in
>the documentation standards. For example, the Rec may be required to
>present every testable assertion in a certain format.

Yes, very applicable here.

>All I can see
>for conformance to the Framework is the identification of people who
>will perform the various tasks that the Framework requires to be
>performed.

And applicable here as well.

There may also be some applicability to actual content of test materials, 
depending on how far we go -- how much detail we develop -- with section 4, 
Technical Framework.  There could, for example, be normative requirements 
on test materials that test case definition languages must be XML, and must 
minimally contain certain information (any such rules would be highly 
taxonomy dependent, and would have to be developed with some care to detail).

-Lofton.
Received on Friday, 9 November 2001 12:12:49 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 6 December 2009 12:13:58 GMT