W3C | TAG | Previous: 3 Jun | Next: 17 Jun

Minutes for 10 June 2002 TAG teleconference

Nearby: IRC log · teleconference details · issues list · www-tag archive

1. Administrative (15min)

  1. Confirm scribe: IJ
  2. Roll call: TBL, TB, NW, PC, RF, DO, DC, IJ, SW (later). Regrets: CL.
  3. Next meeting: 17 June. The TAG resolved to maintain the current meeting time.
  4. Accepted 3 June minutes. DC noted that we had published a finding even with an objection from Tantek Çelik. The TAG was satisfied with the fact that both the issues list and the status section of the finding recorded the objection. See Tantek's more recent posting on this topic.
  5. Accepted summary of TAG activity in May 2002. The TAG accepted the structure of the summary (brief comments and links to more information).

1.2 Completed actions

2. Technical

  1. New issues
  2. Findings in progress:
    1. When to use GET, SOAP and GET
    2. Qnames as identifiers
  3. Arch document
  4. Postponed

2.1 New issues?

2.2 Findings in progress, architecture document

See also: findings.

  1. Pending NW: Draft a finding for formattingProperties-19; fout out source of issue from CSS WG.
  2. Continued DC: Research the bug in the svg diagram for internet media type finding; see DC reply.

2.2.1 When to use GET, SOAP and GET

  1. URIs, Addressability, and the use of GET (whenToUseGet-7 finding)
    1. ACTION CL 2002/05/05: Add concern regarding non-western characters to the POST scenario. Withdrawn since Martin Duerst supplied text.
    2. ACTION IJ 2002/05/20: Revise and publish whenToUseGet-7 finding Also, per 27 May teleconf, action to incorporate comments from SW. Discussion postponed until 10 June since IJ not at 3 June meeting, update still pending. Done.
    3. ACTION DO 2002/6/03: Report to the XMLP task force that for operations where GET would be appropriate SOAP nodes should provide the ability to use GET. Done.

    RESOLVED: Accept "URIs, Addressability, and the use of HTTP GET" Delete section 8.2. IJ may incorporate some of the related material up front.

Summary: The TAG then discussed a response from XMLP WG (TAG-only) about the use of GET in SOAP. The TAG resolved to:

  1. Thank the XMLP WG for their work on this issue.
  2. Raise a related interoperability question with the Web Services Architecture Working Group.

Discussion:

[Ian]

TB:
  1. I think that XMLP WG has, in scenarios, added examples of when GET is appropriate. They have asserted that in these cases, that should use GET. No information about shape of URI.
  2. And that SOAP nodes "should do the right thing with this"
  3. And the primer was updated as well to reflect all of this.

    DO: People commented about moving the GET binding earlier in primer.

[TimBL]
No parameter encoding algorithm.
[Ian]
TBL: In examples, is there indication about which algorithm to use?
[DanC]
yes? really? there's an algorithm? I got the distinct impression that no, there's no algorithm.
[Ian]
TB: There is no machinery for the parameter encoding.
DO: The TAG didn't ask for this.
TB: We made a proposal.
DO: But the TAG didn't say that the XMLP WG had to do a binding.
RF: The XMLP WG has satisfied this issue as much as the HTTP spec does this.
TB: They have done so not only "de jure" but with some measure of enthusiasm.
TBL: But there's a binding in the POST case.
TB: In the POST case, there is an envelope in both directions. With GET, they just say use HTTP.
RF: One of the fundamental principles of HTTP is that it doesn't define the syntax of the URI.
TBL: People will look to the SOAP spec to tell them how to encode.
DO: My best reading of this, is that the idea of developing machinery was thought to be fairly complicated and didn't really address the issue that GET should be used. Having arbitrary mappings between SOAP and HTTP-encoded parameters was not the main issue.
SW: I would summarize slightly differently - the perception that SOAP is a framework for exchanging messages. If you are going to do the URI thing, you want to be able to do with any SOAP message, not just one that is a subset of SOAP (RPC with simple parameters). How would you do this in the general case of a SOAP message?
[DanC]
I have to stipulate that as long as their primer and such is clear on when to use GET, there's no longer an architectural problem with SOAP. I'm kinda bummed that we didn't get interoperable getStock("YHOO") while we're at it, but I'll live. Maybe we'll get that later.
[Ian]
TB: Is there a way to generate a URI from WSDL to do GET?
PC: This is one of the reasons why the task force of the XMLP WG didn't want to do this; they thought that, e.g., wsdl 1.2 might describe how to do this.
DO: WSDL 1.1 does have a binding to HTTP GET and to POST.
TB: Can you generate an appropriate URI from the WSDL?
[PC reads a message from Noah M.]
TB: We want to avoid the case of google, for example, moving services out of GET space. Does the XMLP WG proposal allow us to satisfy this goal?
PC, DO: Yes.
TB: We asked them to make sure that things don't vanish out of URI space. They've done that. The second thing (perhaps more important) is the rhetoric that surrounds this. I think that we are well on the way towards the primer conveying to use GET for safe operations.
[Roy]
WSDL is a better place to contruct URI from an RPC interface.
[PaulC]
From Noah Mendelsohn (quoted with permission):

Henrik's suggestion is fine with me. I would also might add, and I think this is correct, that (1) the appropriate representation might depend on the URI scheme being used...for example, whether the URI scheme is hierarchical (http) vs. non (UUID) (2) that in many cases the appropriate mappings will be application dependent and (3) there will be many opportunities to integrate this with a description language such as WSDL, and those opportunitites are not available to usin the SOAP spec. In short: we aren't against there being standard conventions applied in certain cases: we believe that the SOAP spec is not architecturally the right place to do it.

[Ian]
DO: The XMLP WG did not provide a mapping between inbound SOAP request infoset and GET. Some people think this is an issue; others do not.
[Roy]
I am satisfied with the XMLP work on addressing the issues.
[Ian]
RF: There are ways to encourage people to use HTTP GET when it's easier to use them. All that's necessary is that the protocol allows and supports it (rather than making it illegal).
TBL: I think the XMLP WG work has been great. But I have a concern that the gap is unforgeable.
TB: I think we should send a message to the WSDL WG to ask them to ensure that the machinery allows people to make available information in URI space.
[TimBL]
>1 issue here.
[Roy]
I agree with TB.
[Ian]
PC: There has already been email on that WG's mailing list. A message to the WG would be a good idea.
TBL summarizing:
  1. We applaud the work of the XMLP WG.
  2. The question remains - how will interoperability be addressed. The interface definition includes the marshalling rule (serializing data for remote operations). I think we should note that this remains to be addressed, and hopes that it will be addressed. But that the interoperability achieved with POST has not yet been achieved with GET.
TB: I think TBL's question is reasonable - given that there is nothing normative said on how to do the mapping, there may be interoperability problems. But it's not clear to me to whom this concern should be addressed.
[Ian]
DO: Perhaps ask the Web Services Architecture Group?
[TimBL]
DO suggested tha they have done all they have to do.
[Ian]
PC: I'm not quite sure why we need to do this? We don't do this for other applications? There are people that use HTTP GET succesfully without them being told how to characterize their parameters.
TBL: The XMLP WG has done this for POST, and this is the format of the message to be sent. I don't see why the same thing would not be necessary when using GET.
[Roy]
I think that the notion that you get interoperability by specifying a POST syntax is completely bogus, for reasons discussed in my dissertation. Any GETable URI has built-in interoperability that far exceeds any SOAP envelope.
[Ian]
DC: Case in point - the Google had working stuff in URI space, SOAP specs came along, and google folks gave up being in URI space.
RF: How is it that you know that a given parameter in a URI reflects a stock quote?
TBL: There is an interface description. You don't know what the syntax of the URI.
RF: I don't need a spec; I can see what millions of people are doing on the Web. How interfaces are specified in WSDL is another problem.
[Roy]
Payload does not belong in the URI.
[Ian]
DO: I think that RF is right on here - SOAP specifies what to do in POST since there is no format otherwise; but there is a format for GET.
TBL: Are you referring to the format you use when you fill in an HTML form? The HTML spec says how to do this; the URL spec talks about "?" but not the syntax of what follows. TBL: Are you relying on the HTML semantics?
[TimBL]
DO: People can go on using HTML form encoding.
[Ian]
DO: My second point - if the TAG had agreed that XMLP should do the binding, we should have told them.
TB: DO and I proposed using the HTML form encoding. But I agree that the correct thing for the TAG to do at this point is to say that the XMLP WG did what we asked. I think it's reasonable to raise a further concern: Will the Web Services folks explain how we will get interoperability in the GET case?
SW: SOAP tells you how to form a message, but not what parameters to use. You can get this from WSDL.
TBL: To get a URL for a service is one thing, to get a URL for parameters is another thing (that might be complicated; e.g., with reg exps).
DO: I suggest that we send to Web Services CG instead.
DC: I would prefer to make a guess and send to the arch wg
PC: I think the CG is the right place, due to weight of requests from TAG.
TBL: We could send back to the XMLP WG since they know the issue well, and ask them who should address this. I note that there is disagreement on this call about the role of a CG.
DC: They work better by exception. I think that the WSA WG is a pretty good guess in this case.
RESOLVED: Send request to the WSA WG.
DC: I'm happy with whatever DO writes.
Action RF: Send thank you message to XMLP WG.
Action DC: Write up architecture concern. (DO will champion in WSA WG).
DO: WSA WG has a ftf meeting in France starting Weds this week.
ACTION DO/TB/CL 2002/05/05: Pending XMLP response, polish up DO's .1-level draft and find out what's going on with XForms.
Status unclear; part of the action seems to be subsumed, but the part about XForms may be open.

2.2.2 Qnames as identifiers

Review of QNames as Identifiers (qnameAsId-18).
NW: I added some recommendations to the end. There has been some discussion. I could do another round of edits.
DC: I would have an easier time reviewing this if it started with an example.
TB: I agree with the finding. I suggest salting with examples.
NW: I have resorted to examples in email to expalin it.[The TAG supports more examples and diagrams in the world!]
Action NW: Add examples to Qnames finding.
TBL: I think that we should identify holes in the architecture (e.g., frag ids).
IJ: Norm, one minor comment: In section 4, would bullet 4 be clearer as bullet 2?
DC: Related but separate issue: rdfmsQnameUriMapping-6
DC: Norm, please include reference to issue 6 in your finding.
NW: I will do that.
TB: I had an action on rdfmsQnameUriMapping-6. I would like to note for the record that there was a lack of input on www-tag that this was an important issue. I do not observe the crowd brandishing their firebrands to take up this issue. I suggest we close issue 6.
DC: I don't want to do that without TBL here since I think he cares.

3. Architecture document

  1. Continued IJ 2002/03/18: Integrate/combine one-page summaries (Revised 7 June)
  2. Continued TBL: Talk to w3c management to finalize allocation of IJ time to TAG.

[Ian]

TB: I like the terse style of 7 June draft. If we don't have any material for chapters 3 and 4, maybe we should delete them.
DC: I don't think that will be the case.
TB: Dictionary entries are created by examination of usage instances. They stack them and build a TOC.
DO: I like the terseness. I think it gives us a basis for reference.
TB: Sprinkle the whole thing with examples.
DO: Do you see examples in the arch document or a separate primer?
TB: Inline. Use a good example to replace 3 paras of prose.
DO: I have some concerns, but ok to move forward in current direction.

4. Postponed

  1. RFC3023Charset-21
  2. charmodReview-17:
  3. Status of URIEquivalence-15. Relation to Character Model of the Web (chapter 4)? See text from TimBL on URI canonicalization and email from Martin in particular.
  4. If we get here: httpRange-14, namespaceDocument-8
Ian Jacobs, for TimBL
Last modified: $Date: 2002/06/11 16:38:16 $