W3C home > Mailing lists > Public > public-ldp-wg@w3.org > November 2012

Re: How to request for the number of members of a container ?

From: Ashok Malhotra <ashok.malhotra@oracle.com>
Date: Tue, 20 Nov 2012 05:34:51 -0800
Message-ID: <50AB86FB.6030004@oracle.com>
To: public-ldp-wg@w3.org
Steve:
In the thread started by this Olivier's note, Erik suggested defining a few standard
metadata properties for a container that could be queried as suggested in 5.1.2.
The metadata properties would, of course, be extensible.

Shall we open an issue so we can discuss this?
All the best, Ashok

On 11/20/2012 5:29 AM, Steve K Speicher wrote:
>> From: Olivier Berger<olivier.berger@it-sudparis.eu>
>> To: public-ldp-wg@w3.org,
>> Date: 11/19/2012 04:38 PM
>> Subject: How to request for the number of members of a container ?
>>
>> Hi.
>>
>> I cannot seem to quickly find a mention on how one may "query" a LDP
>> Container for it's number of contained members/Resources... (call it
>> count / len(gth) "primitives", if you will) :-/
>>
>> I don't have my printed copy of the specs at hand to check and couldn't
>> spot an easy answer browsing the HTML document.
>>
>> Is this worth an Issue or am I missing the obvious ?
>>
> The idea is that this number would be ever evolving, especially with
> pagination, therefore a meaningful number would be hard to maintain.  As
> for the number of members of a container that you have in hand, it is
> usually best to rely on software library (like length()) or manually count
> to give you an accurate number.  If the server return it with the
> representation, then the client would still be left to deal with the fact
> when the numbers are different (computed vs. given).  So I believe leaving
> it off might be best.
>
> One could argue the point that we could raise an issue, reach this
> conclusion, then no spec action is taken.  At least then we'd have it
> "recorded".
>
> Thanks,
> Steve Speicher
> IBM Rational Software
> OSLC - Lifecycle integration inspired by the web ->
> http://open-services.net
>
>
Received on Tuesday, 20 November 2012 13:35:32 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:11:42 UTC