IRC log of tagmem on 2002-04-29
Timestamps are in UTC.
- 14:19:36 [RRSAgent]
- RRSAgent has joined #tagmem
- 14:19:40 [Zakim]
- Zakim has joined #tagmem
- 14:20:58 [Ian]
- Ian has changed the topic to: TAG teleconf http://www.w3.org/2002/04/29-tag
- 14:21:30 [Stuart]
- Stuart has joined #tagmem
- 14:24:40 [Stuart]
- zakim, who is here
- 14:24:41 [Zakim]
- Stuart, you need to end that query with '?'
- 14:24:47 [Stuart]
- zakim, who is here?
- 14:24:49 [Zakim]
- sorry, Stuart, I don't know what conference this is
- 14:25:04 [DanCon]
- Zakim, this is tag
- 14:25:05 [Zakim]
- ok, DanCon
- 14:25:09 [DanCon]
- Zakim, who's here?
- 14:25:11 [Zakim]
- I see ??P29
- 14:25:39 [Stuart]
- Hiya Dan
- 14:25:52 [Stuart]
- zakim, ??P29 is probably me
- 14:25:53 [Zakim]
- +Stuart?; got it
- 14:26:47 [Norm]
- Norm has joined #tagmem
- 14:27:13 [DanCon]
- Stuart, I did some scribbling in http://www.w3.org/2001/tag/doc/get7.html , but didn't make any really interesting progress.
- 14:28:41 [Chris]
- Chris has joined #tagmem
- 14:29:01 [Zakim]
- +N.Walsh
- 14:29:32 [Stuart]
- Ok... maybe we can get a quick update. Also, do you think it would be useful to discuss Larry's proposal?
- 14:30:00 [Ian]
- /me will be there in 1 minute
- 14:30:28 [Stuart]
- http://lists.w3.org/Archives/Public/www-tag/2002Apr/0243.html
- 14:31:00 [Zakim]
- +ChrisL
- 14:31:07 [TBray]
- TBray has joined #tagmem
- 14:31:18 [Norm]
- 0824, Dan
- 14:31:59 [Norm]
- zakim, who's here?
- 14:32:01 [Zakim]
- I see Stuart?, N.Walsh, ChrisL
- 14:32:03 [Zakim]
- +DanC
- 14:32:04 [Chris]
- Zakim, who is here?
- 14:32:05 [Zakim]
- I see Stuart?, N.Walsh, ChrisL, DanC
- 14:32:14 [Zakim]
- +??P34
- 14:32:23 [Norm]
- zakim, p43 is Roy
- 14:32:25 [Zakim]
- sorry, Norm, I do not recognize a party named 'p43'
- 14:32:27 [Chris]
- Zakim, ??P34 is Roy
- 14:32:28 [Zakim]
- +Roy; got it
- 14:32:46 [Norm]
- Yes, DanCon is right. I let my pilot remember, not Zakim, that's all.
- 14:33:28 [Zakim]
- +TBray
- 14:36:31 [Zakim]
- +Ian
- 14:36:53 [Ian]
- Regrets: PC, TBL
- 14:36:56 [Ian]
- zakim, who's here?
- 14:36:57 [Zakim]
- I see Stuart?, N.Walsh, ChrisL, DanC, Roy, TBray, Ian
- 14:37:28 [Ian]
- SW: Minutes accepted for 22 April: http://www.w3.org/2002/04/22-tag-summary
- 14:38:33 [Ian]
- IJ: I propose to drop arch doc progress since I've made none.
- 14:39:15 [Ian]
- SW: General question about TAG agenda; driven from proactive to reactive.
- 14:39:27 [Ian]
- ...do others feel they'd like the balance to be more active than reactive?
- 14:39:32 [Ian]
- RF: I'd rather be working on the document.
- 14:39:46 [Ian]
- TB: It's important to not let the arch doc languish.
- 14:39:49 [Ian]
- CL: Agreed.
- 14:39:50 [Chris]
- agree
- 14:40:08 [Ian]
- TB: Let's put that on ftf agenda:
- 14:41:46 [Ian]
- IJ: I ack the problem of my inavailability these days.
- 14:42:01 [Ian]
- [FTF AGENDA: Unplugging IJ the bottleneck. :)]
- 14:42:22 [Ian]
- TB: IJ is not de facto available; what should we do? Should we do some of the editing ourselves?
- 14:44:28 [Ian]
- CL: It would give IJ less work if we polish our own sections.
- 14:45:26 [Ian]
- NW: With respect to: http://www.w3.org/2001/tag/doc/docmeaning.html
- 14:45:38 [Ian]
- NW: My efforts petered out since I haven't heard consensus of opinion on some piecs.
- 14:45:45 [Ian]
- s/piecs/pieces/
- 14:45:54 [DanCon]
- I'm quite happy with folks writing their own opinion and asking if other folks agree, Norm.
- 14:46:31 [Ian]
- CL: Not clear whether this section is addressing just "document-like" resources or all resources.
- 14:46:47 [Ian]
- NW: Trying to address all resources. Not sure that document v. data is useful architecturally.
- 14:47:36 [Ian]
- IJ: XAG 1.0 finds interesting to distinguish data-centric and user-centric content; but no formal distinction.
- 14:48:02 [Ian]
- SW: What about RF's writing on application state?
- 14:48:07 [Ian]
- http://lists.w3.org/Archives/Member/tag/2002Mar/0023.html
- 14:48:20 [Ian]
- RF: TBL, IJ, RF talked about this section.
- 14:48:29 [DanCon]
- ACTION Norm: take another pass over "what does a document mean" before the f2f"
- 14:48:48 [Ian]
- RF: Ball is in IJ's court.
- 14:48:57 [Ian]
- ------------------
- 14:49:01 [Ian]
- Action item review:
- 14:49:04 [Ian]
- Closed:
- 14:49:11 [Ian]
- IJ: Publish draft finding on Media-Types (after edits)
- 14:49:26 [Ian]
- See comments from SW:
- 14:49:41 [Ian]
- http://lists.w3.org/Archives/Member/tag/2002Apr/0050.html
- 14:49:51 [Ian]
- CL: Prioritize comments on Guidelines for the use of XML in IETF protocols
- 14:50:10 [Ian]
- (CL will read these in other agenda items)
- 14:50:24 [Ian]
- Pending - DC: Write more on whenToUseGet
- 14:50:35 [Ian]
- -----------------------------
- 14:50:39 [Ian]
- New issues
- 14:50:50 [Ian]
- 1) Review charmod lc2
- 14:50:54 [Ian]
- http://lists.w3.org/Archives/Member/tag/2002Apr/0036.html
- 14:51:00 [Ian]
- 2) Qnames as ids
- 14:51:06 [Ian]
- http://lists.w3.org/Archives/Public/www-tag/2002Apr/0204.html
- 14:51:15 [Chris]
- Get url of document from http://lists.w3.org/Archives/Member/tag/2002Apr/0049.html
- 14:51:21 [Ian]
- * Charmod
- 14:51:25 [Stuart]
- q?
- 14:51:36 [Zakim]
- +DOrchard
- 14:51:37 [Chris]
- q+
- 14:51:38 [Ian]
- RF: Covers character requirements for every protocol. It's architectural in that it touches everyone.
- 14:52:27 [Ian]
- CL: Charmod introduces ability to put unicode-encoded URI ref in a document. Makes it a req that protocols say when it happens.
- 14:52:42 [Ian]
- ...Stuff you send over the wire is percent-encoded. But you can put company names in URIs.
- 14:53:03 [Ian]
- ...(e.g., on the side of a bus). Conversion to percent (hex) encoding doesn't change what goes over the wire.
- 14:53:06 [DanCon]
- I don't agree with the summary that Chris just gave.
- 14:53:25 [Ian]
- RF: I don't think that IRI will exist for long; not integrated in the URI draft.
- 14:53:53 [Ian]
- RF: I was opposed to IRI four years ago because they wanted to integrate it before having implementing it.
- 14:53:54 [David]
- David has joined #tagmem
- 14:53:55 [Ian]
- q?
- 14:54:25 [Ian]
- CL: This doc has several sections. Section 3 is on characters. With the exception of sorting, the entire section is a description of current practice.
- 14:54:57 [Ian]
- ...very good that all this is gathered into one place.
- 14:55:12 [Ian]
- CL: Normalization stuff is contentious but has benefits.
- 14:55:19 [DanCon]
- I sure wish they'd split the document. Hmm... I wonder if I asked them for that in so many words.
- 14:55:45 [Ian]
- CL: I with they'd split it up too
- 14:55:53 [Ian]
- CL: I recommend that the TAG review this document.
- 14:55:58 [DanCon]
- I 2nd the request to review
- 14:57:10 [Ian]
- IJ: What makes this document different from xforms? Significant impact on other work?
- 14:57:11 [Ian]
- CL: YEs.
- 14:57:39 [Ian]
- NW: I've committed to review for XML Core. I will send my comments to both core and tag.
- 14:57:46 [Ian]
- DC: Please tune your head differently for two reviews.
- 14:58:03 [Ian]
- CL: I volunteer to review and act as a liaison and coordinate comments.
- 14:58:23 [Ian]
- Action CL: Respond affirmative to Misha Wolf's request to review.
- 14:58:28 [Ian]
- DC: Deadlines?
- 14:58:39 [Chris]
- ACTIOn CL confirm with Misha that TAG will review entire document
- 14:59:09 [Ian]
- Yes.
- 14:59:12 [Chris]
- Last Call period begins 30 April 2002 and ends 31 May 2002.
- 14:59:29 [Ian]
- Action IJ: Add as issue charmod-17
- 14:59:32 [Ian]
- -----------
- 14:59:36 [Ian]
- Qnames as Identifiers
- 14:59:41 [Ian]
- http://lists.w3.org/Archives/Public/www-tag/2002Apr/0204.html
- 14:59:43 [DanCon]
- hmm... TAG to finish its charmod review by 31 May? I doubt it.
- 14:59:55 [Ian]
- CL: I'm seeing increasing use of qnames as ids.
- 15:00:42 [Ian]
- CL gives some scenario that scribe missed: essentially, "Qname is a URI/name pair"
- 15:00:49 [Ian]
- ack Chris
- 15:00:59 [Ian]
- SW: Is there a new issue here?
- 15:01:16 [TBray]
- q+
- 15:01:22 [Ian]
- ack DanCon
- 15:01:56 [Ian]
- DC: I think there is an issue. I think it's a myth that one can rewrite prefixes when one copies part of an xml doc from one section to another.
- 15:02:01 [Ian]
- ack TBray
- 15:02:40 [Ian]
- TB: For the record - I argued intensely when James Clark wrought this on the world that this was the wrong thing to do. I lost that argument. Now that the genie is out of the bottle, I'm not sure what we can say useful about it.
- 15:02:42 [Norm]
- q+
- 15:03:02 [Ian]
- TB: There seems to be consensus that at the end of the day a qname is a URI/local name pair. What else needs to be said?
- 15:03:20 [DanCon]
- I gather Tim Bray's argument can now be summarized as 'I told you so.'
- 15:03:35 [Ian]
- TB: A qname is a prefix plus a string of characters.
- 15:03:42 [Ian]
- CL: What issues bit us?
- 15:03:48 [Chris]
- q+
- 15:03:50 [Ian]
- TB: Bit us in the DOM.
- 15:04:06 [Ian]
- NW: I agree with TB - shouldn't have done this in the first place. But now we need to move on.
- 15:04:22 [DanCon]
- well, as to what we can do about it, I think we can say 'this sucks; sorry; deal; don't expect things to work nicely.
- 15:04:24 [Ian]
- CL: We can say:
- 15:04:26 [DanCon]
- '
- 15:04:32 [Ian]
- a) Yes it's ok to use them
- 15:04:39 [Ian]
- b) We recommend that you use them.
- 15:05:02 [Ian]
- SW: I'm hearing making this an issue and issuing a finding?
- 15:05:09 [Ian]
- q?
- 15:05:13 [Ian]
- ack Norm
- 15:05:14 [Norm]
- ack norm
- 15:05:20 [Ian]
- DC: There's a lot of experience. We can condense it.
- 15:05:33 [Ian]
- DC: Not everyone knows the plusses and minuses.
- 15:05:43 [Ian]
- CL: Yes, I think a finding would be useful.
- 15:05:53 [Ian]
- SW: Volunteers?
- 15:06:25 [Ian]
- Resolved: Accept qnameAsId-18 as issue.
- 15:06:42 [Ian]
- Action NW: Draft a finding explaining advantages and disadvantages.
- 15:06:50 [Ian]
- CL: Keep it neutral - legal but pros and cons.
- 15:07:00 [Ian]
- DO: So it's not really an arch recommendation...
- 15:07:06 [DanCon]
- order, Stu, we're done accepting this issue
- 15:07:13 [Ian]
- q+
- 15:07:19 [Ian]
- ack Chris
- 15:07:24 [Ian]
- ack Ian
- 15:07:38 [Ian]
- Norm, I recommend including examples (in general in fact) of bad usage (and good).
- 15:07:56 [Ian]
- Action IJ: Add issue to issues list.
- 15:07:58 [Ian]
- ---------------------------
- 15:08:47 [Ian]
- Finding: http://www.w3.org/2001/tag/2002/0129-mime
- 15:09:07 [Ian]
- RF notes that IE Mac crashes on this document.
- 15:09:14 [DanCon]
- ooh, TimBray, I'm interested in clues on choosing which mozilla to use on a mac
- 15:09:21 [Ian]
- DC: I move we accept this draft.
- 15:09:26 [Ian]
- RF: I agree with SW comments (on tag@w3.org)
- 15:09:47 [Ian]
- http://lists.w3.org/Archives/Member/tag/2002Apr/0050.html
- 15:10:10 [Ian]
- SW summary of comments:
- 15:10:21 [Ian]
- 1) s/resource/response. Found this a bit jarring.
- 15:10:25 [Ian]
- CL: I agree with this.
- 15:10:52 [Ian]
- DC: The last meeting said "resolved s/resource/response"
- 15:11:05 [Ian]
- TB: The point was that we were talking about the bits received.
- 15:11:27 [Ian]
- DC: What IJ wrote is what I would have expected based on our meeting of last week.
- 15:11:43 [DanCon]
- [[
- 15:11:43 [DanCon]
- Resolved:
- 15:11:43 [DanCon]
- 1. Publish this finding as accepted, without ns dispatch section, and having fixed charset sentence (s/resource/response).
- 15:11:47 [DanCon]
- ]] -- http://www.w3.org/2002/04/22-tag-summary
- 15:11:52 [Ian]
- RF: This is wrong.
- 15:12:22 [Ian]
- RF: The finding says that representations only exist in responses. We're talking about media types.
- 15:12:41 [Ian]
- CL: Don't imply that some things only are found in responses.
- 15:13:02 [Ian]
- TB: I request that we take more time to review offline.
- 15:13:35 [Chris]
- url to read?
- 15:13:36 [Ian]
- DC: How do we make progress on this?
- 15:13:50 [Ian]
- http://www.w3.org/2002/04/22-tag-summary
- 15:13:56 [Ian]
- Wrong uRI
- 15:14:09 [Ian]
- Read: http://www.w3.org/2001/tag/2002/0129-mime
- 15:14:16 [Ian]
- Last modified: $Date: 2002/04/25 17:06:19 $
- 15:14:19 [Ian]
- ----------------------------
- 15:14:22 [Ian]
- FTF meeting agenda
- 15:15:26 [Ian]
- DC: TimBL on holiday this week.
- 15:15:40 [Ian]
- SW: Agenda suggestions?
- 15:15:52 [Ian]
- TB: Two things I'd like to accomplislh:
- 15:16:14 [Ian]
- a) Meta-work on arch document. Style, structure. I'm not satisfied with progress thus far.
- 15:16:35 [Ian]
- b) I'd like to drive a stake through whenToUseGet-7.
- 15:17:16 [Ian]
- TB: Soap 1.2 is going to go to last call soon. I suspect that at least TBL, RF, and I will have some issues about what's in there.
- 15:17:43 [Ian]
- TB: I'd like to be proactive, read SOAP 1.2, and identify architectural issues, come up with an action plan (who does what when).
- 15:18:03 [DanCon]
- if there's a suggestion to read "soap 1.2", please include dates and URIs of the specs; I gather the published /TR/ for SOAP isn't the thing to read.
- 15:18:16 [Ian]
- NW: I'd like progress on arch doc. Let's use ftf time to make progress on that and slow issues.
- 15:18:21 [Ian]
- DO: Sounds fine so far.
- 15:18:30 [Ian]
- RF: Already covered.
- 15:18:34 [Ian]
- CL: Already covered.
- 15:18:53 [David]
- Why is Ian crying?
- 15:18:56 [Ian]
- ;)
- 15:19:22 [Ian]
- DC: Mixed namespaces, if only to show ourselves that we won't make progress.
- 15:19:50 [Ian]
- Action SW and IJ: Work on ftf agenda.
- 15:19:55 [Ian]
- ========================
- 15:20:03 [DanCon]
- Ian's falling on his sword cuz he sees himself as a bottleneck on the arch document, but Tim Bray was careful to say "I think it's important and I'm not satisifeid with the progress *we* are (not) making on it"
- 15:20:04 [Ian]
- 1. Guidelines For The Use of XML in IETF Protocols IETF best practices draft requiring URNs for XML namespaces in IETF documents.
- 15:20:04 [Ian]
- Action to take?
- 15:20:10 [Stuart]
- q
- 15:20:12 [Stuart]
- q?
- 15:21:00 [Ian]
- CL: Some comments on guidelines from editors suggest some fixes will take place (but wouldn't have occurred if charmod already a Rec)
- 15:21:25 [Ian]
- CL: Also, they say "should be well-formed". No. Must be well-formed.
- 15:21:28 [DanCon]
- (alread a REC *and* widely read and understood; unfortunately we can't publish directly into developer's minds)
- 15:21:38 [Norm]
- What Chris said, +100 :-)
- 15:21:51 [Ian]
- CL: I don't want a protocol coming out of IETF saying "Should be well-formed...."
- 15:21:56 [Ian]
- TB: Absolutely.
- 15:22:20 [Ian]
- SW: They expect to "roll a new one" in a week or two.
- 15:22:36 [Ian]
- TB: Larry Masinter has asked us to postpone discussion.
- 15:22:49 [Ian]
- LM: New draft expected "in a couple of weeks"
- 15:23:21 [Ian]
- http://lists.w3.org/Archives/Public/www-tag/2002Apr/0280.html
- 15:23:49 [Ian]
- SW: We will postpone discussion until that draft ready.
- 15:24:02 [Ian]
- --------------------------------
- 15:24:18 [Ian]
- whenToUseGet-7 Review revised Finding, TAG consensus? (
- 15:24:18 [Stuart]
- q+
- 15:24:22 [Stuart]
- q-
- 15:24:31 [Ian]
- Draft findings: http://www.w3.org/2001/tag/doc/get7
- 15:24:34 [Chris]
- http://www.w3.org/2001/tag/doc/get7
- 15:24:49 [Ian]
- DC: See "Fodder" at bottom
- 15:24:53 [Ian]
- (of document)
- 15:25:43 [Ian]
- DC: See email from LM http://lists.w3.org/Archives/Public/www-tag/2002Apr/0243.html
- 15:25:55 [Ian]
- DC: I like this.
- 15:26:00 [Ian]
- TB: I think close to DC's version.
- 15:26:30 [Stuart]
- q?
- 15:26:36 [Ian]
- TB: Would you redraft your language using LM language?
- 15:27:00 [Ian]
- DC: Original findings didn't make the case for what you lose when you don't use get. I would add examples.
- 15:27:21 [Ian]
- DC: Also, the "browsers v. clients" distinction I don't agree with. I wanted to make this case.
- 15:29:12 [Ian]
- CL: If I bookmark results of submitting a form, I don't want the form posted again. I just want a URL to tracking info. In other cases, I do want form to be resubmitted each time. There are cases for each.
- 15:29:40 [Ian]
- TB: When you buy a book, for the safety criterion, this has to be done with a post anyhow. I think we are mixing the issues here.
- 15:29:51 [Ian]
- DC: LM pointed out that POST response can give a content location.
- 15:30:01 [Ian]
- TB: That's a safe way that's playing by the rules.
- 15:30:10 [Ian]
- RF: It isn't necessary to be limited to content location.
- 15:30:44 [Ian]
- CL: I'd like to have the option of bookmarking a post (when posts are safe).
- 15:30:50 [Ian]
- DC: If safe, shouldn't have been a POST.
- 15:30:55 [Ian]
- CL: Where do you put the message body?
- 15:31:11 [Ian]
- TB: If too complex, existing GET machinery probably not enough. Use Post.
- 15:31:21 [Ian]
- CL: Bad to crunch message bodies into percents.
- 15:31:25 [Ian]
- DC, TB: Why?
- 15:31:36 [Ian]
- CL: No meaning of bytes in URI space.
- 15:32:35 [Ian]
- RF: In practice, the only problem is when the char encoding is transcoded at some point. The body no longer corresponds to the same octets the server had.
- 15:32:36 [DanCon]
- Ian, don't try to minute this line by line.
- 15:32:40 [Ian]
- CL: I disagree with that.
- 15:33:26 [Ian]
- TB summarizing: CL is objecting to the utility in the general case of doing GETs on URIs that have complex args due to I18N issue.
- 15:33:39 [Ian]
- TB: Is that orthogonal to the main arch issue we are discussing?
- 15:33:56 [Ian]
- CL: No, since this is telling people to use something that's broken.
- 15:34:11 [DanCon]
- I don't think anything's broken.
- 15:34:32 [Ian]
- TB: Two sides to this - if you push web to post space, you lose a lot of benefits (e.g., application of crawlers, bookmarks, ...).
- 15:34:38 [Ian]
- TB: Isn't a better solution to fix the I18N solution.
- 15:34:39 [Ian]
- CL: Yes.
- 15:34:46 [DanCon]
- servers define the meaning of all URIs, not just ones with non-ascii form responses.
- 15:35:06 [Ian]
- CL: I still think kind of broken to percent-encode a document and stuff into a URI...
- 15:35:21 [Ian]
- DC: I can make same argument against pointy brackets...
- 15:35:44 [Ian]
- CL: If we recommend something, indicate corresponding drawbacks.
- 15:36:26 [Ian]
- DC: Do you agree with principle to use get for safe operations?
- 15:36:42 [Ian]
- CL: Yes, unless strong reasons to the contrary.
- 15:36:49 [Ian]
- TB: That's why it's "should".
- 15:36:57 [Chris]
- yeah, okay
- 15:37:04 [Ian]
- TB: I think DC's original document was sounds, and that DC should incorporate suggested improvements.
- 15:37:21 [Ian]
- RF: I'd like to refocus on the issue of "All important resources should have URIs."
- 15:38:13 [Ian]
- DO: Before getting closure here, how is this finding to be used?
- 15:38:21 [TBray]
- q+
- 15:38:34 [Ian]
- DO: What is Web services to do with this?
- 15:39:01 [Ian]
- TB: Yes, I agree - some of our findings will be impactful on ongoing work. I think we need to be explicit about intended consequences.
- 15:39:25 [Chris]
- q+
- 15:39:26 [Ian]
- DC: I'd like SOAP primer to say "At this time we don't have GET, so for safe operations don't use SOAP."
- 15:40:02 [Ian]
- TB: At ftf meeting, we can discuss how to build findings and how to work with people to incorporate.
- 15:40:05 [Ian]
- q?
- 15:40:10 [Ian]
- ack TBray
- 15:40:11 [David]
- q+
- 15:40:37 [Ian]
- DC: The example used recently - Google API - you can use with GET or SOAP.
- 15:41:04 [Ian]
- DC: I would like (SOAP) specs to be clear that SOAP is not expected to be used for GET-like operations (e.g., get the weather).
- 15:41:26 [Ian]
- CL: The document primarily talks about HTTP. And talks about GET (but not safe methods).
- 15:41:55 [Ian]
- CL: It seems to me that one thing missing from finding - protocols should indicate their safe methods.
- 15:42:10 [Stuart]
- q?
- 15:42:26 [Ian]
- DC: SOAP is not a w3c-defined vocab of methods. "Make your own"
- 15:42:33 [Ian]
- DC: There are bindings to transport protocols.
- 15:42:51 [Ian]
- CL: If you see a new protocol you haven't met before, you should have a mechanism for querying whether a method is safe.
- 15:43:01 [Ian]
- RF: E.g., include a label in envelope?
- 15:43:05 [Ian]
- CL: Yes, for example.
- 15:43:24 [Ian]
- CL: In short: move away from the word "GET" and use "safe" instead.
- 15:43:27 [Ian]
- q?
- 15:43:31 [Ian]
- ack Chris
- 15:43:55 [TBray]
- q+
- 15:44:24 [Ian]
- DO: I put a proposal out that one of the ways to handle this for the TAG to issue a finding that hiding everything behind POST isn't sufficient, and the TAG would like something more Web-friend (URIs and GET) and we'd like the WSA WG to deal with this issue.
- 15:44:48 [Ian]
- DO: The WSA WG has responsibility for glossary, examples, charters, etc.
- 15:45:13 [Ian]
- DO: This is not part of charter for SOAP 1.2. We could ask WSA to make this a high priority for later versions.
- 15:45:25 [Stuart]
- q?
- 15:45:28 [DanCon]
- sounds mostly good, but the "merry path" should include some "NOTE: this is an issue SOAP 1.2 doesn't address; stay tuned" stuff in the SOAP 1.2 spec
- 15:45:55 [Stuart]
- ack David
- 15:46:22 [Ian]
- TB: I think that this is the best way forward for process. I'm left with a grave concern for timing. What worries me is that huge amounts of info disappear behind POST>
- 15:47:00 [Ian]
- TB: Damage will be done if SOAP 1.2 goes to Rec creating an all-POST environment for Web services.
- 15:47:07 [Ian]
- q?
- 15:47:11 [Ian]
- ack TBary
- 15:47:25 [TBray]
- q-
- 15:47:33 [Ian]
- SW: People asking how to integrate GET. Responses have been "You could do that, but that wouldn't be very useful."
- 15:47:35 [David]
- q+
- 15:47:57 [Ian]
- SW: The WG is working on the document. There is a small window of opportunity.
- 15:48:49 [Stuart]
- q?
- 15:48:52 [Ian]
- CL: Problem is if SOAP 1.3 is produced with safe methods but SOAP 1.2 meets everyone's needs adequately.
- 15:50:06 [Ian]
- DO: Things the WSA WG will be interesting to the Web services community (e.g., reliable methods). Therefore, I think a next version of SOAP with cool features including safe methods will not get lost.
- 15:50:40 [Ian]
- RF: In the IETF, the IESG can add a note at the beginning of the spec to say that additional work is going on to take care of issues a/b/c.
- 15:51:09 [DanCon]
- hmm... I don't think delaying SOAP 1.2 for this is the best idea, but the idea that stuff after SOAP 1.2 will get noticed... I wonder... there's a LOT of stuff being built now that cites SOAP 1.1.
- 15:51:26 [Ian]
- TB: HTTP/1.1 has been slow to catch on.
- 15:51:30 [Ian]
- q?
- 15:51:43 [Ian]
- q+
- 15:52:17 [DanCon]
- RF/CL disagree with TB about speed of HTTP/1.1
- 15:52:33 [Ian]
- DO: What does the TAG think the XMLP WG should do with SOAP 1.2. I'm strongly arguing that the WG should be able to make progress (as is).
- 15:52:37 [Ian]
- ack David
- 15:54:15 [TBray]
- q+
- 15:54:55 [Ian]
- ack Ian
- 15:55:20 [Ian]
- IJ: I think that TAG should provide comprehensive explanation of issue. Let larger community reach consensus as part of regular W3C process.
- 15:55:22 [Ian]
- ack TBary
- 15:55:24 [Ian]
- ack TBray
- 15:55:39 [Ian]
- TB: I think this is a problem that is not hard to solve technologically.
- 15:55:59 [Ian]
- TB: Do some people think it's much harder than what I've described elsewhere?
- 15:56:33 [Ian]
- TB: Wouldn't cover all of SOAP (e.g., not N-space conversations).
- 15:56:47 [Ian]
- DO: How do RF and DC feel about this type of solution.
- 15:56:49 [Ian]
- DC: It's good.
- 15:56:50 [DanCon]
- as to the idea that this issue is coming in late, I notified the XMLP WG of this issue, via Yves, when they were drafting their requirements. R612 http://www.w3.org/TR/2001/WD-xmlp-reqs-20010319/#N1423
- 15:58:51 [Ian]
- TB: Paul Prescod wrote an xml.com article about google - they published an API where there used to be a URI. The google result space vanishes from URI space as a result. Paul argues why the URI version was better for a lot of reasons.
- 15:59:02 [Ian]
- DO: I thought the article was well-written.
- 15:59:31 [Ian]
- http://www.xml.com/pub/a/2002/04/24/google.html
- 15:59:37 [TBray]
- http://www.xml.com/pub/a/2002/04/24/google.html
- 16:00:08 [Ian]
- DC: It would help me if DO said which way Google should have done it - it was done with GET and they switched. If there isn't agreement that it was better done with GET, I don't know how to write the finding.
- 16:00:53 [Ian]
- DO: I think that GET could be used for some of the SOAP calls. I don't like raising the case for using POST in general. But in the case of google, I think it's a fine usage of GET.
- 16:01:39 [Zakim]
- -DanC
- 16:02:00 [Ian]
- Adjourned
- 16:02:02 [Zakim]
- -Roy
- 16:02:04 [Zakim]
- -TBray
- 16:02:08 [Zakim]
- -Ian
- 16:02:10 [Zakim]
- -N.Walsh
- 16:02:10 [Zakim]
- -Stuart?
- 16:02:30 [Ian]
- RRSAgent, stop