to close ISSUE-18 and ISSUE-26 with the insight that we require that any compliant implementation SHOULD treat every HTTP request atomically, and that we don't want to go any further in specifying transacionality and concurrency link

Close ISSUE-23 with the insight that HTTP negotiation mechanism (as discussed in sparql11-protocol) is sufficient. link

14:11:00 <AxelPolleres> alex: concerns raised, shortcuts for language not yet existing, increased learning curve ... I still think that these operations are so common that shortcuts are justified.

Alexandre Passant: concerns raised, shortcuts for language not yet existing, increased learning curve ... I still think that these operations are so common that shortcuts are justified. [ Scribe Assist by Axel Polleres ] ←

14:30:53 <pgearon> I believe that we've addressed several of issues for Update, but the issues have remained open

Paul Gearon: I believe that we've addressed several of issues for Update, but the issues have remained open←

14:31:26 <AxelPolleres> PROPOSED: to close ISSUE-18 and ISSUE-26 with the insight that we require that any compliant implementation SHOULD treat every HTTP request atomically, and that we don't want to go any further in specifying transacionality and concurrency

PROPOSED: to close ISSUE-18 and ISSUE-26 with the insight that we require that any compliant implementation SHOULD treat every HTTP request atomically, and that we don't want to go any further in specifying transacionality and concurrency←

14:32:38 <AxelPolleres> RESOLVED: to close ISSUE-18 and ISSUE-26 with the insight that we require that any compliant implementation SHOULD treat every HTTP request atomically, and that we don't want to go any further in specifying transacionality and concurrency

RESOLVED: to close ISSUE-18 and ISSUE-26 with the insight that we require that any compliant implementation SHOULD treat every HTTP request atomically, and that we don't want to go any further in specifying transacionality and concurrency←

14:33:57 <pgearon> The current text is: "Exposing RDF data for update creates many security issues which any deployment must be aware of, and consider the risks involved. This submission does not describe such issues."

Paul Gearon: The current text is: "Exposing RDF data for update creates many security issues which any deployment must be aware of, and consider the risks involved. This submission does not describe such issues."←

14:34:14 <NicholasH> Axel: should there be a seperate section on Security?

14:35:31 <AlexPassant> proposal is "the specification does not address security concerns related to SPARQL/Update and that implementers and users MUST be aware of security concerns when allowing SPARQL/Update on their dataset"

Alexandre Passant: proposal is "the specification does not address security concerns related to SPARQL/Update and that implementers and users MUST be aware of security concerns when allowing SPARQL/Update on their dataset"←

14:35:33 <AxelPolleres> "the specification does not address security concerns related to SPARQL/Update and that implementers and users MUST be aware of security concerns when allowing SPARQL/Update on their dataset" from Alex' mail

Axel Polleres: "the specification does not address security concerns related to SPARQL/Update and that implementers and users MUST be aware of security concerns when allowing SPARQL/Update on their dataset" from Alex' mail←

14:35:33 <NicholasH> Axel: should not attempt to list all the secutiry issues, but should outline some of the high level problems

Axel Polleres: should not attempt to list all the secutiry issues, but should outline some of the high level problems←

14:49:16 <AndyS> sec 5 : "Removed the section on SOAP bindings, and referred to other WSDL bindings in general"

Andy Seaborne: sec 5 : "Removed the section on SOAP bindings, and referred to other WSDL bindings in general"←

14:49:21 <sandro> sandro: it should be a big, red, editor's note saying "Hey, we're dropping this because we think no one's using it. If you are using it, please let us know!"

Sandro Hawke: it should be a big, red, editor's note saying "Hey, we're dropping this because we think no one's using it. If you are using it, please let us know!" [ Scribe Assist by Sandro Hawke ] ←

14:49:34 <AndyS> and some text mention of SOAP ... so to Sandro's Q: no.

Andy Seaborne: and some text mention of SOAP ... so to Sandro's Q: no.←

14:50:50 <AxelPolleres> ACTION: LeeF add a note on dropping of SOAP binding to next WD of protocol11 and explicitly solicit feedback on usage of SOAP in SPARQL

ACTION: LeeF add a note on dropping of SOAP binding to next WD of protocol11 and explicitly solicit feedback on usage of SOAP in SPARQL←

14:50:50 <trackbot> Created ACTION-286 - Add a note on dropping of SOAP binding to next WD of protocol11 and explicitly solicit feedback on usage of SOAP in SPARQL [on Lee Feigenbaum - due 2010-08-03].

Trackbot IRC Bot: Created ACTION-286 - Add a note on dropping of SOAP binding to next WD of protocol11 and explicitly solicit feedback on usage of SOAP in SPARQL [on Lee Feigenbaum - due 2010-08-03].←

14:51:12 <ivan> [[[For all new features, backwards compatibility with the current version of SPARQL is of great importance. All queries, that are valid in the January 2008 version of SPARQL, should remain valid in the new version and should produce identical results. For each new feature, if there is doubt or a perceived problem with respect to this, the guideline should be to not include the feature in the set of additions.

Ivan Herman: [[[For all new features, backwards compatibility with the current version of SPARQL is of great importance. All queries, that are valid in the January 2008 version of SPARQL, should remain valid in the new version and should produce identical results. For each new feature, if there is doubt or a perceived problem with respect to this, the guideline should be to not include the feature in the set of additions.←