- From: John Arwe <johnarwe@us.ibm.com>
- Date: Wed, 15 Oct 2014 10:51:42 -0400
- To: James Leigh <james@3roundstones.com>
- Cc: "public-ldp-wg@w3.org Group" <public-ldp-wg@w3.org>
- Message-ID: <OF4B1BFAD7.B1C2CC0A-ON85257D72.00517FE2-85257D72.0051A4A1@us.ibm.com>
works for me James. any objections from others, speak up, otherwise it sounds like an editorial change that's pretty easy to handle. Best Regards, John Voice US 845-435-9470 BluePages z/VM OpenStack Enablement and zKVM From: James Leigh <james@3roundstones.com> To: John Arwe/Poughkeepsie/IBM@IBMUS Cc: "public-ldp-wg@w3.org Group" <public-ldp-wg@w3.org> Date: 10/10/2014 02:42 PM Subject: Re: LDPR Interaction Model on Create Hi John, If the spec simply said the resulting resource is LDPR, but there are no assurances of any LDPC support, I would be satisfied. Is that middle ground enough? Thanks, James From: John Arwe Sent: Friday, 10 October, 2014 11:28 To: James Leigh; public-ldp-wg@w3.org Group Subject: Re: LDPR Interaction Model on Create Attempting to move this off of the comments list and onto the WG mailing list, given that the former has extra tracking hence is not intended for "long" discussions. public-comments is more for comments from those outside the WG, and where we try to get down to problem-solution-ok triples. We discuss proposed responses along with internal WG stuff (still public, just less tracked by automation for document transitions) on public-ldp (no -comments) and in meetings. Once we have a consensus proposal we can use public-comments. I don't think your proposal to list the prohibitions is a good idea, for several reasons: 1: It was never the intent IMO to *prohibit* all LDPC behaviors, it was the intent to say that the client guarantee is that it's an LDPR, and therefore (like any LDPR) it might have additional non-standard behaviors (including some LDPC behaviors). If we prohibit, we can't un-prohibit later and remain compatible. 2: Listing the prohibitions means recapping all LDPC MUSTs in a single place, inverting them, and keeping that up to date as the rest of the spec changes. People are horrible at making that model work over time. If a middle ground works for you, like listing all the current LDPC-Musts that client is not guaranteed to get with an LDPR interaction model *informatively* along with a statement saying that list might be incomplete, I might go for that - I do have sympathy for spec readers in addition to editors. Best Regards, John Voice US 845-435-9470 BluePages Cloud and Smarter Infrastructure OSLC Lead
Received on Wednesday, 15 October 2014 14:52:15 UTC