[CTG] Draft 2008-11-07 / Testing

a)	Testing interface

Section 5 states that operators of transcoders should
make available interfaces to facilitate testing. This
is a worthwhile goal -- and I would really appreciate
to be able to figure out how specific transcoders
behave. However, to be useful, that statement needs
to be fleshed out: what facilities must such an
interface provide? The issues related to HTTP header
fields, content tasting, return values, etc, make it
clear that a testing interface is no trivial matter.

If, on the other hand, what is meant is some form of
direct access to the transcoder (in the same way one
can access skweezer, mowser or GWT from any browser),
then this should be formulated clearly. From that
perspective, developers would be able to send HTTP
requests directly to the transcoder, and see what
happens.


b)	Normal Internet access paths

I am wary of using the word "normal", since it immediately
brings to mind the notion of normalization (e.g. of
database schemas, of statistical values, of lexical
elements). If what was meant is "usual", then use that
word.


c)	Normal Internet access paths (II)

Given the current state of the art, we can consider 
that there are at least two usual access paths for
Internet applications:
1. traditional browsing of URI over HTTP.
2. Web services (i.e. SOAP/WDSL mechanisms).
The document must state clearly what access paths are
meant.

E.Casais

Received on Tuesday, 11 November 2008 09:37:30 UTC