- From: Ian B. Jacobs <ij@w3.org>
- Date: Mon, 29 Apr 2002 17:40:40 -0400
- To: www-tag@w3.org
Hello,
The 29 Apr 2002 TAG teleconference summary is
available as HTML [1] and is quoted below as text.
- Ian
[1] http://www.w3.org/2002/04/29-tag-summary
=========================================================
Summary of 2002-04-29 TAG teleconference
Note: This is an edited version of the 29 Apr 2002 TAG
IRC log.
Previous meeting: 22 Apr 2002 [Minutes approved at this
meeting]
Next meeting: 5 May ftf meeting. See TAG home for more
meeting information.
Participants: Tim Bray (TB), Dan Connolly (DC), Roy
Fielding (RF), Chris Lilley (CL), David Orchard (DO),
Norm Walsh (NW), Stuart Williams (SW), Ian Jacobs (IJ,
Scribe)
Regrets: Tim Berners-Lee, Paul Cotton
Agenda
See initial agenda:
1. Review of action items
2. Making progress on architecture document
3. New issue: Review of "Character Model for the Web"
4. New issue: Qnames as IDs
5. Status of finding on Internet Media Type
registration, consistency of us
6. TAG ftf meeting agenda
7. What action to take on "Guidelines for the use of
XML in IETF protocols"?
8. Status of finding on When to use GET?
Summary of resolutions:
1. Accept as issue charmodReview-17 the "Character
Model" review request.
2. Accept qnameAsId-18 as issue.
Action items
Closed:
* IJ: Publish draft finding on Media-Types (after
edits). But see (tag-only) comments from SW.
* CL: Prioritize comments on Guidelines for the use of
XML in IETF protocols. [Gone over during this
meeting].
Open:
* DO: Write text about "Web as information space", to
be integrated by IJ
* IJ: Integrate one-page summaries
* TBL: Take question of HTTP Query to W3C/IETF liaison
(issue whenToUseGet-7)
* TBL: Draft comments on RDF+HTML for namespace
documents.
* TBL: Take uriMediaType-9 finding to IETF and IANA.
* RF: Write up discussion of RFC3205 based on www-tag
input.
Making progress on architecture document
[Ian]
SW: General question about TAG agenda; driven
from proactive to reactive. Do others feel they'd
like the balance to be more active than reactive?
RF: I'd rather be working on the document.
TB: It's important to not let the arch doc
languish.
CL: Agreed.
TB: Let's put this question on the ftf agenda:
How to make progress on the arch document.
IJ: I acknowledge the problem of my
inavailability these days due to concurrent
projects.
TB: IJ is not de facto available; what should we
do? Should we do some of the editing ourselves?
CL: It would give IJ less work if we polish our
own sections.
Digression into section "What does a document mean?"
[Ian]
NW: With respect to: "What does a document
mean?": My efforts petered out since I haven't
heard consensus of opinion on some pieces.
[DanCon]
I'm quite happy with folks writing their own
opinion and asking if other folks agree, Norm.
[Ian]
CL: Not clear whether this section is addressing
just "document-like" resources or all resources.
NW: Trying to address all resources. Not sure
that document v. data is useful architecturally.
IJ: XAG 1.0 finds interesting to distinguish
data-centric and user-centric content; but no
formal distinction.
SW: What about RF's writing on application state?
RF: TBL, IJ, RF talked about this section. The
ball is in IJ's court to write down the ideas.
[DanCon]
Action NW: take another pass over "what does a
document mean" before the face-to-face meeting.
New issue: Review of "Character Model for the Web"
Refer to preliminary review request from Misha Wolf
(Member-only).
[Ian]
RF: Covers character requirements for every
protocol. It's architectural in that it touches
everyone.
CL: Charmod introduces ability to put
unicode-encoded URI ref in a document. Makes it a
req that protocols say when it happens. Stuff you
send over the wire is percent-encoded. But you
can put company names in URIs (e.g., on the side
of a bus). Conversion to percent (hex) encoding
doesn't change what goes over the wire.
[DanCon]
I don't agree with the summary that Chris just
gave.
[Ian]
RF: I don't think that IRI will exist for long;
not integrated in the URI draft. I was opposed to
IRI four years ago because they wanted to
integrate it before having implementing it.
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.
It will be very good that all this is gathered
into one place. Normalization stuff is
contentious but has benefits.
[DanCon]
I sure wish they'd split the document. Hmm... I
wonder if I asked them for that in so many words.
[Ian]
CL: I with they'd split it up, too. I recommend
that the TAG review this document.
[DanCon]
I 2nd the request to review
[Ian]
IJ: What makes this document different from
xforms (see issue xformsReview-4), its
significant impact on other work?
CL: Yes.
NW: I've committed to review for XML Core. I will
send my comments to both core wg and tag.
DC: Please tune your head differently for two
reviews.
CL: I volunteer to review and act as a liaison
and coordinate comments.
Resolved: Accept as issue charmodReview-17 the
"Character Model" review request; CL will
coordinate the TAG's review comments.
Action CL: Respond affirmative to Misha Wolf's
request to review entire document.
Action IJ: Add charmodReview-17 to issues list.
[Chris]
Last Call period begins 30 April 2002 and ends 31
May 2002.
[DanCon]
hmm... TAG to finish its charmod review by 31
May? I doubt it.
New issue: Qnames as IDs
Refer to question from Joseph Reagle
[Ian]
CL: I'm seeing increasing use of qnames as ids.
CL gives some scenario that scribe missed:
essentially, "Qname is a URI/name pair"
SW: Is there a new issue here?
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.
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. 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?
[DanCon]
I gather Tim Bray's argument can now be
summarized as 'I told you so.'
[Ian]
TB: A qname is a prefix plus a string of
characters.
CL: What issues bit us?
TB: This bit us in the case of the DOM.
NW: I agree with TB - shouldn't have done this in
the first place. But now we need to move on.
[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.
[Ian]
SW: I'm hearing CL suggesting to make this an
issue and issuing a finding?
DC: There's a lot of experience. We can condense
it. Not everyone knows the plusses and minuses of
qnames.
CL: Yes, I think a finding would be useful.
SW: Volunteers?
Resolved: Accept qnameAsId-18 as issue.
Action NW: Draft a finding explaining advantages
and disadvantages.
Action IJ: Add this to the issues list.
CL: Keep it neutral - legal but pros and cons.
DO: So it's not really an arch recommendation.
[Ian]
Norm, I recommend including examples, good and
bad usage, etc.
Status of finding on Internet Media Type registration,
consistency of use
Refer to still draft finding on Internet Media Type
registration, consistency of use
Last modified: $Date: 2002/04/29 21:35:01 $
RF notes that IE Mac crashes on this document.
[DanCon]
ooh, TimBray, I'm interested in clues on choosing
which mozilla to use on a mac
[Ian]
DC: I move we accept this draft.
RF: I agree with SW comments (on tag@w3.org)
SW summary of comments: s/resource/response.
Found this a bit jarring.
CL: I agree with this.
DC: But at the the last meeting said "resolved
s/resource/response" resolved: Publish this
finding as accepted, without ns dispatch section,
and having fixed charset sentence
(s/resource/response).
TB: The point was that we were talking about the
bits received.
DC: What IJ wrote is what I would have expected
based on our meeting of last week.
RF: This is wrong. The finding says that
representations only exist in responses. We're
talking about media types.
CL: Don't imply that some things only are found
in responses.
TB: I request that we take more time to review
offline.
Homework: review this finding for next meeting.
TAG ftf meeting agenda
[Ian]
DC: TimBL on holiday this week.
SW: Agenda suggestions?
TB: Two things I'd like to accomplish:
1. Meta-work on arch document. Style, structure.
I'm not satisfied with progress thus far.
2. I'd like to drive a stake through
whenToUseGet-7.
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. I'd like to be
proactive, read SOAP 1.2, and identify
architectural issues, come up with an action plan
(who does what when).
[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.
[Ian]
NW: I'd like progress on arch doc. Let's use ftf
time to make progress on that and slow issues.
DO, RF, CL: Agree with above requests.
DC: Mixed namespaces, if only to show ourselves
that we won't make progress.
Action SW and IJ: Work on face-to-face meeting
agenda.
What action to take on "Guidelines for the use of XML in IETF
protocols"?
[Ian]
CL: Some comments on guidelines from editors
suggest some fixes will take place (but wouldn't
have occurred if charmod already a Rec). Also,
they say "should be well-formed". No! Must be
well-formed XML.
[DanCon]
(already a REC *and* widely read and understood;
unfortunately we can't publish directly into
developer's minds)
[Norm]
What Chris said, +100 :-)
[Ian]
CL: I don't want a protocol coming out of IETF
saying "Should be well-formed...."
TB: Absolutely.
SW: They expect to "roll a new one" in a week or
two.
TB: Larry Masinter has asked us to postpone
discussion; see request from LM.
LM: New draft expected "in a couple of weeks"
SW: We will postpone discussion until that draft
ready.
Status of finding on When to use Get?
See DC's edits to findings on whenToUseGet-7.
[Ian]
DC: See "fodder section" at bottom of document.
See email from LM; I like his comments.
TB: I think LM's version is close to DC's
version. Were you thinking of redrafting your
language using LM language?
DC: The original findings didn't explain what you
lose when you don't use GET. So I would like to
add examples. Also, I don't agree with the
"browsers v. clients" distinction, so I'd like to
make that case, too.
CL: There are cases when I want to bookmark the
results of submitting a form and upon return
re-POST, and other cases where I do not want to
re-POST (I just want a URL to track info).
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.
DC: LM pointed out that POST response can give a
content location.
TB: That's a safe way that's playing by the
rules.
RF: It isn't necessary to be limited to content
location.
CL: I'd like to have the option of bookmarking a
POST (in safe case).
DC: If safe, shouldn't have been a POST.
CL: Where do you put the message body?
TB: If too complex, existing GET machinery
probably not enough. Use Post.
CL: Bad to crunch message bodies into percents.
DC, TB: Why?
CL: No meaning of bytes in URI space (an
internationalization issue).
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.
CL: I disagree with that.
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. Is that
orthogonal to the main arch issue we are
discussing?
CL: No, since this is telling people to use
something that's broken.
[DanCon]
I don't think anything's broken.
[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, ...). Isn't a
better solution to fix the I18N solution?
CL: Yes.
[DanCon]
servers define the meaning of all URIs, not just
ones with non-ascii form responses.
[Ian]
CL: I still think kind of broken to
percent-encode a document and stuff into a URI...
DC: I can make same argument against pointy
brackets...
CL: My point is that if we do recommend something
(such as using GET and putting message body in a
URI), then we need to indicate corresponding
drawbacks to the approach.
DC: Do you agree with principle to use get for
safe operations?
CL: Yes, unless strong reasons to the contrary.
TB: That's why it's "should".
[Chris]
yeah, okay
[Ian]
TB: I think DC's original document was sound, and
that DC should incorporate suggested improvements
from www-tag.
RF: I'd like to refocus on the issue of "All
important resources should have URIs."
DO: Before getting closure here, how is this
finding to be used? What is Web services to do
with this?
TB: Yes, I agree - some of our findings will be
have a real impact on ongoing work. I think we
need to be explicit about intended consequences
when we publish findings.
DC: I'd like SOAP primer to say "At this time we
don't have GET, so for safe operations don't use
SOAP."
TB: At our ftf meeting, we can discuss how to
build findings and how to work with people to
incorporate.
DC: The example used recently - Google API - you
can use with GET or SOAP. See article by Paul
Prescod at xml.com.
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).
CL: The document primarily talks about HTTP. And
talks about GET (but not safe methods). It seems
to me that one thing missing from finding -
protocols should indicate their safe methods.
DC: SOAP is not a w3c-defined vocab of methods.
"Make your own"
DC: There are bindings to transport protocols.
CL: If you see a new protocol you haven't met
before, you should have a mechanism for querying
whether a method is safe.
RF: E.g., include a label in envelope?
CL: Yes, for example.
CL: In short: move away from the word "GET" and
use "safe" instead.
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. The WSA WG has responsibility
for glossary, examples, charters, etc. This is
not part of charter for SOAP 1.2. We could ask
WSA to make this a high priority for later
versions.
[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
[Ian]
TB: I think that this is the best way forward in
terms of process. However, I'm left with a grave
concern for timing. What worries me is that huge
amounts of info disappear behind POST. Damage
will be done if SOAP 1.2 goes to Rec creating an
all-POST environment for Web services.
SW: People asking how to integrate GET. Responses
have been "You could do that, but that wouldn't
be very useful." The WG is working on the
document. There is a small window of opportunity.
CL: Problem is if SOAP 1.3 is produced with safe
methods but SOAP 1.2 meets everyone's needs
adequately.
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.
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.
[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.
[Ian]
TB: HTTP/1.1 has been slow to catch on.
[DanCon]
RF/CL disagree with TB about speed of HTTP/1.1
[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).
IJ: I think that TAG should provide comprehensive
explanation of issue. Let larger community reach
consensus as part of regular W3C process.
TB: I think this is a problem that is not hard to
solve technologically. Do some people think it's
much harder than what I've described elsewhere
(see comments on www-tag). This wouldn't cover
all of SOAP (e.g., not N-space conversations).
DO: How do RF and DC feel about this type of
solution.
DC: It's good.
[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: See
scenario R612.
[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.
DO: I thought the article was well-written.
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 here that
it was better done with GET, I don't know how to
write the finding.
DO: I think that GET could be used for some of
the SOAP calls. I don't like raising the bar for
using POST in general. But in the case of google,
I think it's a fine usage of GET..
Adjourned
--
Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs
Tel: +1 718 260-9447
Received on Monday, 29 April 2002 17:42:34 UTC