- From: Andy Seaborne <andy.seaborne@epimorphics.com>
- Date: Mon, 28 Jan 2013 11:58:59 +0000
- To: public-ldp-wg@w3.org
On 24/01/13 20:39, Nandana Mihindukulasooriya wrote: > Hi, > > On Thu, Jan 24, 2013 at 5:42 PM, Alexandre Bertails <bertails@w3.org > <mailto:bertails@w3.org>> wrote: > > Just a question: Is it only during the creation time > when the POSTed content contains > > <> a ldp:Container . > > that that action creates a Container? > > Or can one later append that triple to any resource to > turn it into a container? > > > I was expecting something like that to come up... And that's a > legitimate question. I would say that POSTing this triple to a > non-LDPC should not create a new container. But then, it brings other > questions, like, what does it mean when a client dereference the LDPR > and see this triple? > > > I also think it should not. However, LDP applications can / may decide > whether this conversion is allowed or not based on their own application > restrictions. But what is important is that server should ensure it is > in a consistent state. So if a server allows this triple to be added, > the server should consider that the LDPR is converted to a LDPC and it > should behave as an ldp:Container for that point on wards. I think the triple should only be allowed when the thing is created. There seem to be various corner cases otherwise (e.g. presence of some container triples already in an LDP-R). Andy > Alternatively, if a server decides that clients can not convert an LDPR > to an LDPC once is created, it should discard the '<> a ldp:Container' > triple in any of the updates (servers would normally do the same for > system managed properties like created time, etc) or as in the current > spec for some specific protocol data > [[ > 5.5.2 LDPC servers may allow updating LDPC non-membership properties > using HTTP PUT on <containerURL>?non-member-properties, which may > exclude server-managed properties such as ldp:membershipSubject and > ldp:membershipPredicate. > ]] > > Best Regards, > Nandana
Received on Monday, 28 January 2013 11:59:35 UTC