Re: [CTG] Draft 2008-11-07 / Testing

comments inline

On 11/11/2008 09:36, Eduardo Casais wrote:
> 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.

The conformance statement would be a place to detail the first and the 
second is what is intended in this section.

> 
> 
> 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.

Conventional might be a better 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.

I take path to mean physical arrangements not protocols but if that's 
not clear we should discuss it.

> 
> E.Casais
> 
> 
>       
> 
> 
>

Received on Tuesday, 11 November 2008 09:59:27 UTC