Re: Process & Operational Guideline - Test materials home

Thanks Daniel for the response....
I Agree with what you said.  Perhaps my problem is the wording of the 
Guideline - to me, it implied the physical location of the test suite had 
to be on a W3C web server.

lynne
:

> > The Framework: Process & Operational Guideline: Section 2.2.2.2 Test
> > materials home contains the following Guideline:
> > --GUIDELINE: Test Suites and tools should ultimately reside in W3C.
> >
> > I disagree with this statement.  Since we do recognized that external (to
> > W3C) organizations may be developing test suites and tools that the WG
> > wishes to leverage - it is unreasonable to assume that these external
> > organizations would give their products (to reside) to W3C.  By doing so,
> > takes the websurfer off their site, which may be how the get revenue,
> > recognition, impact, etc.   It is reasonable that the WG may wish to
> > recognize these tests and link to them.  I also disagree with Reason #2, -
> > although some test suites are developed by ad-hoc entities others are 
> built
> > and supported by 'real' organizations that won't go away.  And, although
> > the people who built the tests may disappear (same as what happens in a 
> W3C
> > WG), the organizations will still exist (e.g. NIST, Open Group, ETSI)
>
>
>The spirit of the checkpoint is to give the W3C WG in charge of the
>technology control over the test suite development and evolution, both
>from a correctness point of view and later on (when our framework is
>implemented) from a process and operational/presentation point of
>view.
>
>In theory, this could be achieved with the tool/web pages residing on
>an external server, and good coordination going on between the
>external group managing the bits and the W3C WG.
>In practice, depending on a lot of factors, this may be done more
>easily if the bits are on w3.org, with the same repository access
>available to everyone (e.g. cvs server, amaya editing).
>But there may be cases where the persons maintaining the bits are less
>W3C editing-aware and prefer to work on an external server, so we
>should not make that checkpoint a MUST.
>
>I agree that the important thing (the MUST) is that the bits are
>available free of charge for use, but also free of charge for download
>and potential derived/new evolution (this way if the external
>organization fails to maintain the bits, W3C or someone else can
>always take the ball from there).