| [Thread Prev]
| [Thread Next]
| [Date Next]
| [Thread Index]
| [List Home]
Subject: Minutes: XDI TC Telecon Friday 2012-06-01
- From: Drummond Reed <firstname.lastname@example.org>
- To: OASIS - XDI TC <email@example.com>
- Date: Fri, 1 Jun 2012 20:36:45 -0700
Following are the minutes of the unofficial telecon of the XDI TC at:
Date: Friday, 01 Junw 2012 USA
Time: 9:00AM - 10:30AM Pacific Time (16:00-17:30 UTC)
***** NEWS & UPDATES *****
--- W3C CHECK-IN
Kaliya explained that she met last weekend with Harry Halpin about the collaboration between and the W3C Federated Web activity. They discussed the need to address past tensions and build positive relationships between the XDI TC and the W3C in order to avoid potential misunderstandings about XDI
Kaliya suggested that if we have any TC members who are coming to Boston this summer, it would be ideal to meet with Tim Berners-Lee and key folks from the W3C.
We wondered if there was a specific event it could align with, but there was no obvious event.
We also discussed the option of trying to arrange a meeting at the Cloud Identity Summit July 16-20 in Vail. Mike, Drummond, and Kaliya are all planning to attend. Markus is also a possibility.
--- SPACIOUSNESS NEXT WEEK
Travis Wellman of Spaciousness is scheduled to give us a presentation at the start of next week’s call. Markus explained that Travis works for the Internet Archive. His project, Spaciousness, is building a graph model for the WWW, and Markus thought it would be good for us to learn about it and Travis to learn about XDI.
***** PRESENTATIONS *****
--- XDI DICTIONARY PATTERNS
Drummond uploaded a new version of the XDI Graph Patterns document with a complete set of XDI dictionary patterns last night.
We did not take time to review it yet as we wanted to give the decision point queue priority. See the final section.
***** DECISION POINT QUEUE REVIEW *****
--- DECISION POINT PROCESS
Last week we agreed to structure calls around a Decision Point Queue. However we did not conclude about how we will compose and maintain that queue. Bill started to reorganize the home page of the wiki and Drummond and Mike have done further work on that. However Drummond said that from past experience, using page links on the home page may not be the best way to maintain the decision point queue.
We discussed the option of using Jira and agreed that it was far superior but decided in favor of the wiki option because it provides an easier way to document and reference each proposal.
We agreed to the following steps for maintaining the decision point queue:
- Each proposal for consideration by the TC must first be written up as a proposal page.
- The proposal page MUST include a CategoryProposal tag and EXACTLY ONE of the following Category Priority tags: CategoryCurrent, CategoryHighPriority, CategoryMediumPriority, CategoryLowPriority. This will allow all proposals to appear automatically on the CategoryProposal page (http://wiki.oasis-open.org/xdi/CategoryProposal).
- CategoryCurrent is reserved for proposals that are on the agenda for the next TC call for discussion.
- On the CategoryProposal page we will keep additional notes about the priority of the queue as needed.
Once a proposal has been decided on by the TC, the decision together with the key points of the rationale both for and against it MUST recorded on the proposal page (for future reference if we need to revisit the decision).
- In addition, the Category Priority tag MUST be replaced with a CategoryClosed tag.
This has been recorded at http://wiki.oasis-open.org/xdi/XdiProposalDrafting.
--- PROPOSED DECISION POINTS
The only decision we agreed to add to the queue is:
• Prioritizing the XDI 1.0 specifications
Mike suggested we create categories for each Core XDI spec, prioritize the categories (by vote), and then address decisions according to the weight of the respective Spec category.
***** DECISION POINT FOR THIS CALL *****
1) SHOULD AN XDI MESSAGE OVER HTTP BE SEND IN A MESSAGE PARAMETER OR IN THE HTTP BODY?
Mike said that the main benefit of using a message parameter is being able to send an XDI message by either a GET or a POST. This allows the greatest flexibility. It also gives us the ability to add other parameters later.
Bill said there were two reasons to putting the message in the body.
1) In many domains, for example the U.S. government, it would be a severe security issue to use a GET to modify a resource.
2) The "principle of least surprise" - this is not what most Web developers would expect.
Giovanni reinforced Bill’s first point that the definition of GET in the HTTP spec requires GET operations to not make changes to resources. The reference is to:
*****EXCERPT from http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.1.1******
"In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested."
Markus prefers sending the message in the HTTP body, as this is what he believes developers would expect, but said there had never been any formal decision by the TC to do this.
Mike checked and the SCIM protocol only made resource changes using an HTTP POST or PUT.
Joseph said that we can always move to using parameters later if it turns out to be needed.
Drummond said that the reason he advocates using the message body is that to the greatest extent possible we want all protocol semantics to be in the body of the XDI message, not tried to the transport layer.
DECISION: The XDI message will go in the body of the HTTP message.
# MARKUS will write a proposal page to document this decision.
***** NEW TOPICS *****
--- USE CASES AND SHORT DESCRIPTIONS
We had a discussion about the role of use cases relative to the development of the protocol. We agreed that it would be helpful to have a canonical use case.
Mike said his capsule summary is "data federation". Bill said he would send a proposed one-sentence summary to the email list.
Mike suggested that we start building a primer using wiki pages that are marked with the category CategoryPrimer.
Drummond also suggested that we have an XDI Primer page that it is the master starting point page.
--- DICTIONARY DECISIONS
Drummond explained that he felt decisions about the XDI dictionary needed high priority because they affect so many other areas of the spec. For example, some of the proposal pages and examples Mike is posting contain graph constructs that are not compatible with the XDI dictionary design Drummond has developed.
Bill said he would be satisfied with any Dictionary spec that has the capability to express the semantics of four existing specs:
• WSDL (http://www.w3.org/TR/wsdl) which embeds the use of XML Schema
• OWL-S (http://www.w3.org/Submission/OWL-S/ ) - the semantic version of WSDL
• DDMS (http://metadata.ces.mil/mdr/irs/DDMS/)
• Dublic Core Metadata Initiative (http://dublincore.org/)
Drummond will create a proposal page highlighting the motivations for the various elements of his dictionary design proposal.
***** NEXT CALL *****
The next call is next week at the regular time.
| [Thread Prev]
| [Thread Next]
| [Date Next]
| [Thread Index]
| [List Home]