W3C home > Mailing lists > Public > public-hydra@w3.org > November 2015

RE: request for verification: paging in TPF

From: Markus Lanthaler <markus.lanthaler@gmx.net>
Date: Thu, 5 Nov 2015 22:41:49 +0100
To: <public-linked-data-fragments@w3.org>
Message-ID: <043301d11812$c7a93c50$56fbb4f0$@gmx.net>
On 3 Nov 2015 at 09:38, Ruben Verborgh wrote:
>> The client should have some safety measures to catch a case like this I
>> guess.
> 
> The point is that this is not possible:
> there might just be a page which still has a triple,
> so the client is forced to keep on following "next" links.

Theoretically that's true. In practice there's probably little hope to find
data after the 10th empty page.


On 3 Nov 2015 at 12:00, Ruben Verborgh wrote:
> Hi Markus,
> 
>> Why not simply "the next link SHOULD NOT point to an empty fragment"?
> 
> Done:
> https://github.com/HydraCG/Specifications/commit/21a41c2eb51f84fb70956e06
> f9f6cc5284 ef28ae#diff-6729052fc293975f6f653a85f03d88b3R542
> 
>>> Can I already use hydra:view?
>> 
>> Yes.
> 
> Done:
> https://github.com/HydraCG/Specifications/commit/c6a27b39f3900879115c4c72
> 581884a9d 7394831
> 
>>>> Btw. have you considered that "fragment IRI" could be misinterpreted as
"IRI
> fragment"?
>>> 
>>> Not yet; we should probably talk about "IRI of the fragment".
>> 
>> Sounds clearer to me.
> 
> Done:
> https://github.com/HydraCG/Specifications/commit/29d419277f9433a3687ae42c
> bb66f1146 dd83324

Fantastic!


> Next steps on my list:
> - go through the entire specification to simplify where possible
>   (I still quite can't believe that something as simple as TPF requires
this much text)

:-)


> - write a test suite that verifies whether a given server implementation
complies with the
> spec
>    (already started; harder than I thought because of the allowed
flexibility)

Cool. What kind of flexibility are you referring to here? Do you think it's
required flexibility or could it be reduced without loosing much?


--
Markus Lanthaler
@markuslanthaler
Received on Thursday, 5 November 2015 21:42:18 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 5 November 2015 21:42:19 UTC