Re: Test cases document updated

El 28/08/13 10:55, Sergio Fernández escribió:
> Dear Raúl,
>
> thanks for the update. I'd try to review the document in the upcoming days.
>
> Just one question: does the test suite is supported by actual tests?
> I've just make a pull form the repository, and the test folder remains
> only with the initial test files created by Eric Prud'hommeaux early
> this year. If so, I'd try to generate a proper test corpus in parallel I
> implement the test suite.

Dear Sergio,

As mentioned in the "Design principles" section, only the test 
definition is provided and not the implementation; this is because of 
the restrictions imposed by domain-specific servers.

However, you can check the Primer for concrete examples of inputs and 
expected outputs.

Kind regards,

> On 27/08/13 14:29, Raúl García Castro wrote:
>> Dear all,
>>
>> I just updated the test cases document according to the current status
>> of the specification (http://www.w3.org/TR/2013/WD-ldp-20130730/). You
>> can find it here:
>> https://dvcs.w3.org/hg/ldpwg/raw-file/default/Test%20Cases/LDP%20Test%20Cases.html
>>
>>
>>
>> Some new tests have appeared and some were removed. Right now, for LDP
>> Core we don't have much of them (5 for LDPRs and 7 for LDPCs).
>>
>> A couple of things to comment:
>>
>> Clarification in 4.5.2
>> ----------------------
>>
>> "4.5.2 [...] LDPR servers that require conditional requests MUST respond
>> with status code 428 (Precondition Required) when the absence of a
>> precondition is the only reason for rejecting the request [RFC6585]."
>>
>> Conditional GETs can be defined with different request header fields
>> (If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match, and
>> If-Range).
>>
>> Therefore, I think that the requirement needs to be updated since there
>> are two possible interpretations for that requirement:
>>
>> .- "LDPR servers that require conditional requests" refers to all the
>> types of conditional GETs. In this case we are just forcing servers to
>> use 428, which is defined as optional.
>> .- "LDPR servers that require conditional requests" refers only to
>> conditional GETs defined using If-Match (i.e., those mentioned above in
>> the paragraph). In this case we are forcing servers to use 428 only with
>> If-Match, remaining optional for the other types of conditional GETs.
>>
>> The original intention seems to be the second option, but I think that
>> the requirement needs to be reworded to avoid misunderstandings (e.g.,
>> "LDPR servers that require the HTTP If-Match header ...").
>>
>> No tests on PUT
>> ---------------
>>
>> Since the use of the If-Match header (4.5.2) is optional, we are not
>> imposing any absolute requirement on PUT apart from the following:
>>
>> "4.4.1 If HTTP PUT is performed on an existing resource, LDPR servers
>> MUST replace the entire persistent state of the identified resource with
>> the entity representation in the body of the request."
>>
>> In it, we are saying that a resource state will always be replaced by
>> the content of any PUT. I.e., a test for this would be to make a PUT and
>> then a GET and to check that what you get back is the same as the entity
>> in the body of the PUT.
>>
>> However, I think that it is not the intended behaviour of PUT and most
>> implementations would not pass this test (at least non-generic LDP
>> servers). Therefore, this requirement is included in the list of
>> non-testable requirements.
>>
>> As a consequence, right now we don't have any test for PUT (in LDP Core).
>>
>> Kind regards,
>>
>


-- 

Dr. Raúl García Castro
http://www.garcia-castro.com/

Ontology Engineering Group
Departamento de Inteligencia Artificial
Universidad Politécnica de Madrid
Campus de Montegancedo, s/n - Boadilla del Monte - 28660 Madrid
Phone: +34 91 336 36 70 - Fax: +34 91 352 48 19

Received on Wednesday, 28 August 2013 09:34:32 UTC