See also: IRC log
MM: Agenda is at: http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2006Feb/0011.html
MM: last week for registering for plenary
MM: Move to approve 1 Feb & 8 Feb minutes
Approved without objection
RESOLUTION: Minutes of 1 February 2006 at http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2006Feb/0006.html are approved
RESOLUTION: Minutes of 8 February 2006 at http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2006Feb/0009.html are approved
MM: Yves to try to organize some social event for F2
<Yves> http://lists.w3.org/Archives/Public/xml-dist-app/2006Jan/0103.html
<dorchard> Will we get to one-way today without noah and chris?
MM: input required from Chris and Noah, postponed.
MM: XOP issue was created, proposed resolution from Herve
HR: pretty straightforward: just a few examples to change.
ACTION: Herve to send closing email to close rec40, and incorporate changes in the edcopy. [recorded in http://www.w3.org/2006/02/15-xmlprotocol-minutes.html#action01]
MM: issue closed with proposed resolution.
DH: Major diff between RoR and true fire-and-forget
is timing (agree with Noah)
... Way out: not about timing, but about the steps to go.
... with Req-opt-resp, need to wait for a response, with
fire-and-forget, not the case.
... key for distinguishing is what contract you have, and in
particular whether the contract mandate waiting for a response.
... 3rd mail: about separating SOAP and WSDL MEPs
DaveO: prefered way: SOAP MEP lower level than WSDL
MEP
... did a binding with recursive binding of SOAP MEP and WSDL MEP
in the asynchronous case.
... not very much liked by the community.
DH: criticism that SOAP MEPs are close to WSDL
MEPs
... idea of having 1-1 correspondance between SOAP MEPs and WSDL
MEPs considered and rejected in async TF.
DaveO: We allow for 1 WSDL MEP to become 1 or 2 SOAP MEPs
MM: URI for SOAP MEPs
Noah: not yet in agreement with Chris
... 1 question: whether to do anything at all.
... talking about creating a URI to refer to the concept of
MEP.
... we have a section about MEP, the URI of this section might be
sufficient.
... Tag said that such things should be avoided. Talking about
document different from talking about the concept.
... added complication, TBL not only should do different URI, but
retrieving URI should get RDF describing the concept.
... good in principle, but do we have the skill? ... ?
... both Chris and I wonder if we have the skills and charter
mandate.
... Chris prefer to do nothing.
... I prefer a middle ground, making a new URI for the concept, but
do simple things when retrieving URI.
... first do HTML at the URI, then can add later some RDF if
needed.
MM: would like to discuss this.
DaveO: against doing anything in this area.
... out of charter and we have no experience in this area.
... can QName and URI refer to abstract things or only to concrete
things?
... depending on specs, can do either.
<noah> I heard DaveO say depending on specs, can do either, which is a crucial distinction
DaveO: way to ask to WG to produce description about URI is not the good way to go.
DH: defining a name means something, even without
defining explicitly semantics for it.
... separate thing from having a deferenceable URI.
... OK to define the name, not OK to define explicite semantics for
it (i.e. not create RDF for it).
... OK to have a deferenceable URI, but only HTML behing it.
... in fact agree with Noah.
MM: DaveO about this position?
DaveO: against it.
... would like to have the full scope of what we have to do.
Noah: DaveO says that can use URI to refer either
concrete or abstract things. OK with that.
... Did URIs to refer to our MEPs.
... then asked to do a third one for concept of MEPs.
... want clarification from DaveO. Think were both against doing
much work on this.
DaveO: wonder about precedence for other WG.
... worry about ongoing list of requests for new identifiers.
<noah> Part of what I said was that in this particular case, I think the URI we already have is clearly for the section. I'm therefore making the case that in this particular case it's "provable" different than for the concept.
<noah> Given that minting a URI in this case seems cheap, I don't see the problem.
DH: Agree for separating concept from document, but should care to not separate them too much.
<noah> I think many WG's will find it tractable and appropriate to name most of their concepts with URIs. In some complex cases, like schema, it's expensive. In the particular case of schema, the investment is being made, to the tune of many person months.
MM: I would like to have a closure on this. WSD has been waiting a good while
<noah> Where I share Dave's hesitancy is that doing the RDF is indeed a step further, and I am not sure the typical WG, or we, have the skills to do it right.
<noah> I agree with Dave O that there's a good case that it's beyond our charter.
MM: Proposal to respond that it's not in our charter.
Yves: was not proposed as input for charter.
Noah: requiring to have URI for mains concept is cheap.
DaveO: if WG wants to mint URI, can agree with that.
<marc> I have to drop off. I'm OK with minting a URI as requested but don't think we should go much further than that
Noah: process document: should make URI for important concepts.
DaveO: charter should say about it.
Noah: charter exists inside the W3C process. Process document creates a framework that WG have to follow.
DaveO: we have been explicit for other things in charter. If semantic web requires URI for each concept, should be in charter.
Noah: against using document URI for concept.
... other than that, OK to do anything.
... whatever we do someone will have some pushback.
DaveO: can live with middle ground.
... think we should not do anything.
Noah: should we tell use the document URI or say we did not mint a URI.
DaveO: OK to say to use document URI.
Noah: think its unwise to use document URI, but can
live with it.
... think we should document that we are blessing the use of
document URI for the concept (preferably in the spec).
MM: Other member opinions...
Herve: would prefer minting a new URI, without creating any RDF.
DH: prefer middle ground. Don't have strong opinion, except no RDF.
Yves: no strong opinion.
<vikas> don't have any opinion, less RDF is good
Yves: doing nothing could be quite difficult, as
its easy to do something.
... no pref between document URI or new URI.
Vikas: no preference in either dirrection.
MM: Group seems to have slight preference for
minting new URI.
... no personnal preference.
<noah> Please record in the minutes that I said I could live with using the same URI for the section and the concept, but only in the interest of generating consensus. Architecturally, I think they should be separate URIs, and think the best cost/performance is the middle course: new URI with, for now, simple HTML representation. Someone can always use content negotiation to offer RDF later.
MM: the WG slightly prefers the option that the WG should create a new URI.. Can you be the owner of this Noah and draft a response to WSD on how we would like to handle this?
Noah: Yes. will draft something in dist-app
ACTION: Noah to draft XMLP response to WSD regarding issue of minting a URI for concept of SOAP MEP
Adjourned.
[NEW] ACTION: Herve to send closing email to close rec40, and incorporate changes in the edcopy. [recorded in http://www.w3.org/2006/02/15-xmlprotocol-minutes.html#action01]
[NEW} ACTION: Noah
to draft XMLP response to WSD regarding issue of minting a URI for
concept of SOAP MEP [NOT recorded in irc minutes, just
postprocessed into minutes]
[End of minutes]