- From: Ian B. Jacobs <ij@w3.org>
- Date: 17 Jun 2003 15:50:36 -0400
- To: www-tag@w3.org
Hello,
The minutes of the 16 June 2003 TAG teleconf are available
as HTML [1] and as text below.
- Ian
[1] http://www.w3.org/2003/06/16-tag-summary
=========================================================
Minutes of 16 June 2003 TAG teleconference
1. Administrative
1. Roll Call: All present - SW (Chair), TBL, TB, DO, DC, PC, RF, NW,
CL, IJ (Scribe).
2. Accepted minutes of [8]9 Jun teleconference
3. Accepted this [9]agenda
4. Next meeting: 23 June
5. Resolved face-to-face meeting scheduling details:
+ Mon, 21 July, those available for lunch should eat heartily
together.
+ Mon, 21 July, convene meeting at 1pm
+ Wed, 23 July, adjourn at 3pm.
6. Summer meeting planning; see [10]request from Stuart
SW: Please follow up on that thread.
7. TAG partcipation in XML 2003? See [11]email from Paul
The TAG supports PC, CL, NW, TB and others participating on behalf
of the TAG at the town hall.
[8] http://www.w3.org/2003/06/09-tag-summary.html
[9] http://www.w3.org/2003/06/16-tag.html
[10] http://lists.w3.org/Archives/Member/tag/2003Jun/0048.html
[11] http://lists.w3.org/Archives/Member/tag/2003Jun/0027.html
1.1 AC feedback and TAG's last call plans
1. Completed DO/PC: Send draft of AC announcement regarding TAG's
last call expectations/thoughts to tag@w3.org.
The TAG received feedback from the W3C Advisory Committee in Budapest
regarding advancing the Architecture Document to last call. DO and PC
prepared a [12]draft announcement for review by the TAG in response to
that feedback.
[12] http://lists.w3.org/Archives/Member/tag/2003Jun/0062.html
Action PC: Propose a second draft to the TAG that has more "heads-up"
information and less "last call" information.
The TAG envisions starting last call on the Architecture Document some
time around the end of July or early August, through September.
2. Technical
2.1 Architecture document
The editor published the [13]16 June 2003 Editor's Draft of the Arch
Doc ([14]changes)
1. Withdrawn action DC 2003/01/27: write two pages on correct and
incorrect application of REST to an actual web page design..
2. Withdrawn action DO 2003/01/27: Please send writings regarding Web
services to tag@w3.org. DO grants DC license to cut and paste and
put into DC writing.
3. Completed action DC 2003/03/17: : Write some text for interactions
chapter of arch doc related to [15]message passing, a dual of
shared state. DC refers us to Conversations and State
Action IJ: Attempt to incorporate relevant bits of
"[16]Conversations and State" into section to be produced by RF.
[13] http://www.w3.org/2001/tag/2003/webarch-20030616
[14] http://www.w3.org/2001/tag/webarch/changes
[15] http://lists.w3.org/Archives/Public/www-tag/2003Mar/0018.html
[16] http://www.w3.org/DesignIssues/Conversations
Actions from 2 June meeting:
1. RF to rewrite section 5. Section 5 is expected to be short.
2. TB to rewrite section 4 based on his [17]proposal for rewriting
section 4and suggestions from the TAG from 2 Jun teleconf.
([18]Done)
3. CL to make available a draft finding on content/presentation
CL: Some progress..
4. DO to update [19]description of [20]issue abstractComponentRefs-37
DO: I got some feedback from RF; expect to have this by the end of
the week.
DC: Please include options for addressing the issue.
5. SW: to continue work on and make available a draft finding related
to the opacity of URIs.
SW: No progress on second draft; I don't expect this week.
The TAG noted the difference between (1) not making inferences by
inspection of a generic URI and (2) well-defined semantics in
specific cases (e.g., HTML form data that is part of a URI when
the form is submitted).
6. Completed action NW: Take a stab at proposed new 4.5, wherever it
ends up ([21]Done).
7. DO: Write up a couple of paragraphs on extensibility for section
4.
8. Completed action IJ: to start incorporating detailed suggestions
on Arch Doc made by the TAG (see [22]IRC log for details). See
[23]16 June 2003 Editor's Draft of the Arch Doc.
[17] http://lists.w3.org/Archives/Public/www-tag/2003May/0101.html
[18] http://www.tbray.org/tag/wa-c4.html
[19] http://lists.w3.org/Archives/Public/www-tag/2003Apr/0089.html
[20] http://www.w3.org/2003/06/24-tag-summary.html#abstractComponentRefs-37
[21] http://lists.w3.org/Archives/Public/www-tag/2003Jun/0042.html
[22] http://www.w3.org/2003/06/02-tagmem-irc.html
[23] http://www.w3.org/2001/tag/2003/webarch-20030616
Actions from 9 June meeting:
1. Completed action IJ (see [24]16 June 2003 Editor's Draft of the
Arch Doc)
1. compare 3.2 text with RFC2396 version 3; compare and
harmonize; leaving about the same amount of text.
2. add a new 3.x section on allocating URIs; taking some text
from rfc2396bis/3.2 and expanding slightly on social aspects.
3. integrate RF's 3.5 into from RFC2396bis into arch doc section
3.3.
4. See additional notes in minutes of [25]9 Jun teleconference
[24] http://www.w3.org/2001/tag/2003/webarch-20030616
[25] http://www.w3.org/2003/06/09-tag-summary.html
The Editor expects to publish another Editor's Draft on or around 20
June, including text from RF, CL, and NW. The TAG will review that
draft to determine whether it should be the basis for the next "TR
page" draft of the Arch Doc, probably the end of the week of 23 June.
2.2 Findings
See also: [26]findings.
[26] http://www.w3.org/2001/tag/findings
2.2.1 Client handling of MIME headers
* [27]Client handling of MIME headers; see [28]summary of comments.
* [29]contentTypeOverride-24
+ Next step on finding "[30]Client handling of MIME headers"
+ [31]Speech Recognition Grammar Specification Version 1.0,
section [32]2.2.2 External Reference by URI
[27] http://www.w3.org/2001/tag/doc/mime-respect.html
[28] http://lists.w3.org/Archives/Public/www-tag/2003May/0099.html
[29] http://www.w3.org/2001/tag/open-summary.html#contentTypeOverride-24
[30] http://www.w3.org/2001/tag/doc/mime-respect.html
[31] http://www.w3.org/TR/speech-grammar/
[32] http://www.w3.org/TR/speech-grammar/#S2.2.2
[Ian]
On interactions with the Voice Browser WG
SW: We haven't heard back from Voice WG on this issue.
Action SW: Ping Voice WG.
DC: I'm not aware of additional discussions about the Voice
spec within the Team.
On adding to the finding text saying server shouldn't guess
information (e.g., charset).
CL: What about text saying "server shouldn't guess (e.g.,
charset) since the server could get it wrong."
DC: For protocol, you can't distinguish server from content
creator.
CL: My point can still be made upstream.
Action IJ: Add this scenario to finding...(content knows what
charset is; server shouldn't make it up)
On (1) authority of client headers sent to server and (2)
connection between PUT and subsequent GET
TB: I think the draft is fine; questions are about missing
pieces. I think the finding hits an 80/20 point.
IJ: What do we say (if anything) about authority of client
headers sent to server? Is the principle symmetric?
DC: I think the principle doesn't apply in the direction
client-to-server. When you post content, I think you are at the
whim of the server.
RF: It's not that server is disregarding the client's
instructions; it's just that it's using someone else's
instructions (the server manager).
DC: In this case, the author has write access to the relevant
directory (e.g., doing HTTP PUT). The author could thereby
change the configuration of that directory.
TB: Somebody claimed that mod dav ignored media type when you
put some content. That seems wrong to me.
RF: Mod dav doesn't ignore. The process that responds to GET
and the one that responds to PUT are different; both are
subject to editing.
CL: Sounds like the representation that you put and the one
that you get are different.
DC: It would be nice if the PUT handler looked at the mime
handler and copied to the right place so the get handler would
see it.
[Chris]
like jigsaw webdav does, for example?
[Ian]
RF: The idea of keeping the content type on the server between
requests is not a principle. The principle should be that the
server should recognize and properly interpret the content
type.
[Chris]
apache webdav treats put same as ftp
[Ian]
TB summarizing: It sounds like default mod dav behavior is to
ignore content type information that's being sent. But that
doesn't sound like it's violating an architectural principle.
RF: The two requests (PUT and GET) are independent.
TB: But it seems like ignoring content type by default is a bad
idea.
RF: Yes.
RF, DC: This is a quality of implementation issue, not an arch
issue.
DC: There's a different rationale for saying that the PUT/GET
agree (principle of least surprise)
TB: Seems like something questionable about media type being
discarded without being looked at.
TBL: PUT makes same assurance that publisher would make; that
distinguishes PUT from POST.
[timbl]
In PUT, the putter is telling the server that the given tghing
is a valid representation of the resource.
[Ian]
TB: I agree with TBL, but I think that PUT with a particular
mime type does not imply that next GET will be of that mime
type.
[DanC]
In particular, the W3C server mangles the $Id:
16-tag-summary.html,v 1.2 2003/06/17 19:27:14 ijacobs Exp $
keywords and such between PUT and GET
[Zakim]
Chris, you wanted to re-argue about resources
[Ian]
CL: Suppose I put something and there are server side includes,
etc. What I GET back could be quite different.
SW: If I were to put a picture (TIF) on the server and the
server generated JPEG/PNG from it....
[DanC]
I'd expect to PUT to doc.html-source rather than doc.html
[Ian]
IJ: I am hearing 2 distinct comments (1) ignoring client's mime
type v. (2) disjoint PUTs and GETs
RF: Problem boils down to minimizing the amount of magic on the
server.
[DanC]
(I note that we had, and still have, the opportunity to observe
that there's a large degree of consensus around the 5May draft
and decide that we've reached the point of diminishing returns
and put a fork in it.)
[Chris]
not ignoring, but it the resource changes between put and get,
then the media type is not the same
[Ian]
RF: Generally in an HTTP interaction, we'd prefer that there be
different URIs between what is put and what is gotten. Put to
most specific URI. Difficulty with this issue in modern times
is that apps that send PUT requests don't send mime type or
don't send proper mime type.
[Chris]
put on most specific uri and get from coneg uri which might be
different
[Ian]
TB: Clearly it's hard to get mad at someone for self-defense in
the face of broken clients. But documents that look like html
might be served as application/xhtml+xml very legitimately. The
whole notion of the default behavior of getting the media type
from the extension is becoming less and less useful. I think
it's architecturally broken if a server throws my headers on
the ground.
TBL: In principle, if you're editing files on an Apache server,
and you've got different variations (e.g., PNGs, SVGs) it's
reasonable to edit specific ones. However, if you are browsing
the Web, you will encounter the generic URIs. When people want
to edit (based on generic URI) and save it back, the system
uses the etag and other sophistication to be able to
distinguish generic thing that is read, and the specific thing
originally gotten. The goal is that the specific one viewed can
be overwritten. The client shouldn't have to model what's going
on inside the server.
[DanC]
(the question of whether and edit to foo should be PUT to foo
or to foo.html is one of the longest-running team internal
threads among the W3C team, I note, without permission)
[Ian]
RF: Then you are putting the metadata that was part of the
request part of the URI for putting.
[DanC]
(I note that we had, and still have, the opportunity to observe
that there's a large degree of consensus around the 5May draft
and decide that we've reached the point of diminishing returns
and put a fork in it.)
[Zakim]
DanC, you wanted to suggest we say "good question; but it's a
different question; do you mind if we queue that one on the
issue list while we finish this one?"
[Ian]
DC: My preference is to add this to the issues list.
TB: I agree with DC - note the PUT issue and move forward
without it in the draft finding.
[timbl]
makes sense to me
[DanC]
putMediaType or some such
[Ian]
Resolved: New issue putMediaType
1) PUT relation to GET is general issue
2) Specific issue is how client header is authoritative
Action IJ: Add new issue to issues list.
3. Not discussed
* [33]URIs, Addressability, and the use of HTTP GET and POST; see
[34]summary of comments. See also [35]comments from Larry
Masinter.
* [36]How should the problem of identifying ID semantics in XML
languages be addressed in the absence of a DTD?
[33] http://www.w3.org/2001/tag/doc/whenToUseGet-20030509.html
[34] http://lists.w3.org/Archives/Public/www-tag/2003May/0099.html
[35] http://lists.w3.org/Archives/Public/www-tag/2003May/0104.html
[36] http://www.w3.org/2001/tag/doc/xmlIDSemantics-32.html
Action IJ 2003/06/09: Turn [37]TB apple story into a finding.
IJ: No progress.
[37] http://www.tbray.org/ongoing/When/200x/2003/04/30/AppleWA
3.1 New issues?
[38]Summary from Stuart
[38] http://lists.w3.org/Archives/Member/tag/2003Jun/0055.html
3.2 Issues that have associated action items
* [39]rdfmsQnameUriMapping-6
+ Action DC 2003/02/06: Propose TAG response to XML Schema
desideratum ([40]RQ-23).
* [41]whenToUseGet-7
+ Next step for [42]revised draft finding?
* [43]namespaceDocument-8
+ Action TB 2003/04/07: Prepare RDDL Note. Include in status
section that there is TAG consensus that RDDL is a suitable
format for representations of an XML namespace. Clean up
messy section 4 of RDDL draft and investigate and publish a
canonical mapping to RDF. See TB's [44]1 June version.
+ Action PC 2003/04/07: Prepare finding to answer this issue,
pointing to the RDDL Note. See [45]comments from Paul
regarding TB theses.
+ Refer to draft TAG [46]opinion from Tim Brayon the use of
URNs for namespace names.
o RF: Folks assume that because the specs say so, URNs
will be persisitent. But persistence is a function of
institutional commitment and frequency of use.
* [47]uriMediaType-9
+ IANA appears to have responded to the spirit of this draft
(see [48]email from Chris Lilley).What's required to close
this issue?
+ Action CL 2003/05/05: Propose CL's three changes to
registration process to Ned Freed. [What forum?]
* [49]URIEquivalence-15
+ SW proposal: Track RFC2396bis where [50]Tim Bray text has
been integrated. Comment within the IETF process. Move this
issue to pending state.
* [51]HTTPSubstrate-16
+ Action RF 2003/02/06: Write a response to IESG asking whether
the Web services example in the SOAP 1.2 primer is intended
to be excluded from RFC 3205
+ See [52]message from Larry Masinter w.r.t. Web services.
* [53]errorHandling-20
+ Action CL 2003/02/06: Write a draft finding on the topic of
(1) early/late detection of errors (2) late/early binding (3)
robustness (4) definition of errors (5) recovery once error
has been signaled. Due first week of March.
* [54]xlinkScope-23
+ Status report?
+ See [55]draft, and [56]SW message to CG chairs.
* [57]contentPresentation-26
+ Action CL 2003/02/06: Create a draft finding in this space.
Due 3 March.
* [58]IRIEverywhere-27
+ Action CL 2003/04/07: Revised position statement on use of
IRIs. CL says to expect this by 21 April.
+ Action TBL 2003/04/28: Explain how existing specifications
that handle IRIs are inconsistent. [59]TBL draft not yet
available on www-tag.
+ See TB's[60]proposed step forward on IRI 27.
* [61]fragmentInXML-28 : Use of fragment identifiers in XML.
1. Connection to content negotiation?
2. Connection to opacity of URIs?
3. No actions associated / no owner.
* [62]binaryXML-30
+ Action TB 2003/02/17: Write to www-tag with his thoughts on
adding to survey.
+ Next steps to finding? See [63]summary from Chris.
* [64]metadataInURI-31
+ Action SW 2003/02/06: Draft finding for this one. See [65]SW
proposal
+ See also [66]TB email on Apple Music Store and use of URI
schemes instead of headers
* [67]xmlIDSemantics-32
+ See [68]Chris Lilley draft finding.
Action NW 2003/05/05: Point Core WG to CL finding once made
public.
* [69]xmlFunctions-34
+ Action TBL 2003/02/06: State the issue with a reference to
XML Core work. See [70]email from TimBL capturing some of the
issues.
* [71]siteData-36
+ Action TBL 2003/02/24 : Summarize siteData-36
* [72]abstractComponentRefs-37
+ See [73]issue description from David Orchard. Next steps?
[39] http://www.w3.org/2001/tag/open-summary.html#rdfmsQnameUriMapping-6
[40] http://www.w3.org/TR/2003/WD-xmlschema-11-req-20030121/#N400183
[41] http://www.w3.org/2001/tag/ilist.html#whenToUseGet-7
[42] http://www.w3.org/2001/tag/doc/get7-20020610.html
[43] http://www.w3.org/2001/tag/open-summary.html#namespaceDocument-8
[44] http://www.tbray.org/tag/rddl/rddl3.html
[45] http://lists.w3.org/Archives/Member/tag/2003Apr/0046.html
[46] http://lists.w3.org/Archives/Public/www-tag/2003Jun/0003.html
[47] http://www.w3.org/2001/tag/open-summary.html#uriMediaType-9
[48] http://lists.w3.org/Archives/Public/www-tag/2003Feb/0302.html
[49] http://www.w3.org/2001/tag/open-summary.html#URIEquivalence-15
[50] http://www.textuality.com/tag/uri-comp-4
[51] http://www.w3.org/2001/tag/open-summary.html#HTTPSubstrate-16
[52] http://lists.w3.org/Archives/Public/www-tag/2003Feb/0208.html
[53] http://www.w3.org/2001/tag/open-summary.html#errorHandling-20
[54] http://www.w3.org/2001/tag/ilist.html#xlinkScope-23
[55] http://lists.w3.org/Archives/Member/tag/2003Mar/0094.html
[56] http://lists.w3.org/Archives/Member/tag/2003Mar/0104
[57] http://www.w3.org/2001/tag/open-summary.html#contentPresentation-26
[58] http://www.w3.org/2001/tag/open-summary.html#IRIEverywhere-27
[59] http://lists.w3.org/Archives/Member/tag/2003Apr/0074.html
[60] http://lists.w3.org/Archives/Public/www-tag/2003Apr/0090.html
[61] http://www.w3.org/2001/tag/ilist#fragmentInXML-28
[62] http://www.w3.org/2001/tag/open-summary.html#binaryXML-30
[63] http://lists.w3.org/Archives/Public/www-tag/2003Feb/0224.html
[64] http://www.w3.org/2001/tag/open-summary.html#metadataInURI-31
[65] http://lists.w3.org/Archives/Member/tag/2003May/0050.html
[66] http://lists.w3.org/Archives/Public/www-tag/2003Apr/0151.html
[67] http://www.w3.org/2001/tag/ilist#xmlIDSemantics-32
[68] http://www.w3.org/2001/tag/doc/xmlIDSemantics-32.html
[69] http://www.w3.org/2001/tag/ilist#xmlFunctions-34
[70] http://lists.w3.org/Archives/Public/www-tag/2003Feb/0309.html
[71] http://www.w3.org/2001/tag/ilist.html#siteData-36
[72] http://www.w3.org/2003/06/24-tag-summary.html#abstractComponentRefs-37
[73] http://lists.w3.org/Archives/Public/www-tag/2003Apr/0089.html
4. Other actions
* Action IJ 2003/02/06: Modify issues list to show that
actions/pending are orthogonal to decisions. IJ and PLH making
substantial progress on this; hope to have something to show in
May.
_________________________________________________________________
Ian Jacobs for Stuart Williams and TimBL
Last modified: $Date: 2003/06/17 19:27:14 $
--
Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs
Tel: +1 718 260-9447
Received on Tuesday, 17 June 2003 15:50:42 UTC