-
Notifications
You must be signed in to change notification settings - Fork 103
PUT for create requires extension of LDP #30
Comments
Yes, this is a non-standard improvement to PUT that we could propose as an extension to LDP. It is currently described (specced) in this doc so that people writing apps for SoLiD can speed things up a bit. In any case, a client can still create the container hierarchy if it is unaware that PUT also creates parent containers. |
It would help then if it were part of the LDP Next Charter. If you don't put it there it won't even be considered.
Why would a client bother trying to do something when there is a chance in 10 or 100 that it will work correctly? Unless the client can know that this will work, there is no reason to guess. Otherwise the client will have to have code such as |
I see your point. I think we can address it in LDP Next, where we plan to have a way for servers to advertise what they support. |
Well the easy way to do that is to specify sublcassses of ldp:Container such as the iContainer I proposed. But it still would help to have wider agreement of the meaning, and have a w3c namespace, so you need to get it explicitly in the charter. |
Getting things into the charter is not that easy. It requires group agreement, so the best I (or you) can do is to suggest it to the group during the next call. |
well in any case, one cannot specify this behavior without indicating that it is available. So one needs to create a subclass of ldp:Container - such as iContainer mentioned in issue 50 http://www.w3.org/2012/ldp/track/issues/50 (but one could extend it, for the more general behavior required here) so that it is clear to clients what they can expect. |
In the section HTTP PUT to create the following is written.
Currently it is not clear how a client would ever know that a server implemented this feature without out-of-band information. Because LDP Containers are not Intuitive Containers, a client has no guarantee that when doing a PUT in a namespace it is even allowed to do so in that part of the name space. Furthermore it has no way of knowing in a standard way that the intermediate directories will be created.
I don't see this listed on the LDP Next Charter, though there is still time to add this feature there if it is felt to be useful enough.
The text was updated successfully, but these errors were encountered: