See also: IRC log
<trackbot> Date: 07 October 2013
<bblfish> hi
<scribe> scribe: pchampin
<Arnaud> http://www.w3.org/2013/meeting/ldp/2013-09-30
PROPOSED: approve minutes from 2013-09-30
<ericP> second approving last week's minutes
<bblfish> I looked at them, but don't know if they reflect what was said
RESOLUTION: approve minutes from 2013-09-30
arnaud: next meeting will be next week, same time
arnaud: anyone claiming victory?
<bblfish> action-47?
<trackbot> action-47 -- Eric Prud'hommeaux to Review the Use Cases section of the document -- due 2013-03-21 -- OPEN
<trackbot> http://www.w3.org/2012/ldp/track/actions/47
arnaud: Erik was supposed to
review the UC a long time ago
... it has been reviewed by other in the meantime; can close
it
<Arnaud> s/erik/eric/
close action-47
<trackbot> Closed action-47.
arnaud: I tried to make it clear
in the agenda what would be discussed, and the decisions that
would be made
... Steve Battle has updated the UC&R with comments.
<sandro> (I did send that. in meeting another meeting.)
<Arnaud> Proposal: Publish the latest editor's draft of the Use Cases & Requirements
<ericP> +1
<TallTed> +1
<roger> +1
+1
<krp> +1
<betehess_> +1
<JohnArwe> +1
<Arnaud> Resolved: Publish the latest editor's draft of the Use Cases & Requirements
RESOLUTION: Publish the latest editor's draft of the Use Cases & Requirements
<bblfish> http://lists.w3.org/Archives/Public/public-ldp-wg/2013Oct/0004.html
arnaud: it is an important
change, as it impacts all implementations
... but there seem to be consensus that we should make this
change
<Arnaud> Proposal: change 5.3.5 SHOULD to MUST per John's email: http://lists.w3.org/Archives/Public/public-ldp-wg/2013Oct/0004.html
<JohnArwe> MOI calls them vanilla/chocolate? WG came up with that.
<JohnArwe> +1
<ericP> +1
<krp> +1
<Ashok> +1
<TallTed> +1
<betehess> +1
<roger> +1
<JohnArwe> I think Steve S would also agree with it, FWIW, since he originally suggested it to me.
<Arnaud> Resolved: change 5.3.5 SHOULD to MUST per John's email: http://lists.w3.org/Archives/Public/public-ldp-wg/2013Oct/0004.html
<bblfish> 5.3.5 -> https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html#ldpc-HTTP_PUT
arnaud: this is in relation with
a comment from Mark Baker
... about us redefining HTTP
<bblfish> this is the article: http://lists.w3.org/Archives/Public/public-ldp-wg/2013Oct/0006.html
<Arnaud> Proposal: changes to 5.6.2 (container delete) per John's email: http://lists.w3.org/Archives/Public/public-ldp-wg/2013Oct/0006.html
arnaud: not that we are contradicting it, but merely being redundant
<JohnArwe> +1
<betehess> +1
<TallTed> +1
<krp> +1
<bblfish> +1
<Ashok> +1
+1
<Arnaud> Resolved: changes to 5.6.2 (container delete) per John's email: http://lists.w3.org/Archives/Public/public-ldp-wg/2013Oct/0006.html
arnaud: the next points in the
agenda are more controversial
... anyone wanting to push one of them forward?
<Arnaud> http://lists.w3.org/Archives/Public/public-ldp-wg/2013Sep/0052.html
john: this is still related to
Mark Baker's remark
... our intent was not to redefine HTTP, but informatively
restate information from other specs
tallted: we will need a restatement of the proposed change, after the discussions in the mailing list
john: I did a mockup of the new sections in the respec draft
<JohnArwe> https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html#base-specs
<JohnArwe> that's a mockup in the editor's draft
<bblfish> did you post the correct URL?
<JohnArwe> bblfish: I pulled it from a live browser henry
tallted: having it in the mailing list archive (not in a mutable draft) would be better to track our decision
arnaud: I agree; can you send such an e-mail, so that we can vote on it next week?
john: I can paste it in the IRC right now
eric: it might be too big, you would get kicked off; better send a mail and copy the URL right afterwards
arnaud: in the meantime, let's move to another topic
<Arnaud> http://lists.w3.org/Archives/Public/public-ldp-wg/2013Sep/0051.html
<bblfish> is that the one or not?
<bblfish> http://lists.w3.org/Archives/Public/public-ldp-wg/2013Sep/0051.html
<JohnArwe> @bblfish: no list; implementation-defined
<JohnArwe> ...IIRC our running assumption was that future work like rdf-val would provide a way for clients to introspect them at run time
<bblfish> Is there a way to tell what the implementation-defined list is automatically?
<JohnArwe> @bblfish: no
<JohnArwe> ...at least not in LDP, not today
arnaud: this anwsers TimBL's concern about the current spec allowing the server to silently ignore some of the PUT triples
eric: shouldn't it happen for all operations altering triples (POST, PUT, PATCH) that they return an error if triples will be dropped?
john: that's what Steve's
distinction between "server managed properties" and "unknown
properties" is about.
... which is a problem because we give the client no way to
tell the difference
arnaud: the problem seems to be the unclear boundary between the protocol and the data
<bblfish> bblfish: There is no way for a client to know what the "server defined server managed properties are". So the proposal currently makes no sense for the client, since it cannot distinguish a vanilla or chocolate server.
arnaud: we try to be good citizen
by reusing existing vocabularies (e.g. dc:modified), but this
may be a mistake
... we have neither a pre-defined list of server-managed
properties, nor a mean for the server to dynamically expose
such a list
<JohnArwe> @ericp: doing so means a typical "patch via put" set of interactions, i.e. GET+ change + PUT, fails
<Zakim> ericP, you wanted to ask how bad it would be if a client were simply given an error if it sent triples that would be rejected
eric: how bad would it be to say that the server issues an error whenever it drops triples?
<betehess> I agree with ericP's view: reject with an error when some triples cannot be accepted
john: a problem is that PATCH would fail whenever you don't change the server-managed properties that would automatically change
<ericP> JohnArwe: the prob with ericP's proposal is the GET/PUT mode of patch where the client GET's data which includes server-managed properties
<betehess> well, it just means that some data is meant to be modified by the user, some data has to be managed by the application (maintained by the server), they should not belong to the same LDPR
bblfish: some properties are statements by the server rather than statements by the document
arnaud: it touches what I was saying earlier about the boundary between protocol and data
<ericP> pchampin: in my implementation, the client is not supposed to modify server-managed properties.
<ericP> ... if there is no attempt to modify those properties, the server accepts and returns a 20x½
<ericP> Arnaud: so that's your way of doing a PATCH
<JohnArwe> It's not clear to me that doing what Pierre does (while logical) conforms with the normative language.
<Zakim> ericP, you wanted to say supposed the server rejects POSTs/PUTs with *unrecognized* properties.
<bblfish> pchampin: how does the client know what it is not allowed to touch?
pchampin: my solution to this
problem is to disallow the client to *modify* the
server-managed properties
... *then* the server changes the values
<bblfish> cool idea: put server managed properties in a meta file
eric: but then the server has to check that the values are actually not modified
<bblfish> +1
<bblfish> meta file is linked to from the original file in a link header
betehess: in our solution, there
are two kinds of LDPR : those entirely managed by the clients,
and those partly managed by the server
... a header field is used to tell the difference
<JohnArwe> informative/diffs reminder before we break
arnaud: this was a useful
discussion
... please post yout proposals to the mailing list in response
to steve's message
... so that we can look at them and think about them
<JohnArwe> link to diffs: https://dvcs.w3.org/hg/ldpwg/rev/eeff2a51723d
<JohnArwe> link to diffs: https://dvcs.w3.org/hg/ldpwg/rev/eeff2a51723d
arnaud: it is almost the end of
the hout
... do we have the time for a quick vote? or do you need more
time?
... I'll put it on the agenda next week, then.
ADJOURNED
<Arnaud> trackbot, end meeting
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) FAILED: s/erik/eric/ Succeeded: s/out intend/our intent/ Succeeded: s/is way/is no way/ Succeeded: s/kinfs/kinds/ Found Scribe: pchampin Inferring ScribeNick: pchampin Default Present: Arnaud, EricP, JohnArwe, Alexandre, Ashok_Malhotra, roger, bblfish, TallTed, pchampin, krp Present: Arnaud EricP JohnArwe Alexandre Ashok_Malhotra roger bblfish TallTed pchampin krp WARNING: Replacing previous Regrets list. (Old list: bart) Use 'Regrets+ ... ' if you meant to add people without replacing the list, such as: <dbooth> Regrets+ steves WARNING: Replacing previous Regrets list. (Old list: steves) Use 'Regrets+ ... ' if you meant to add people without replacing the list, such as: <dbooth> Regrets+ stevebattle WARNING: Replacing previous Regrets list. (Old list: stevebattle) Use 'Regrets+ ... ' if you meant to add people without replacing the list, such as: <dbooth> Regrets+ sandro Regrets: sandro WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 07 Oct 2013 Guessing minutes URL: http://www.w3.org/2013/10/07-ldp-minutes.html People with action items:[End of scribe.perl diagnostic output]