W3C home > Mailing lists > Public > www-tag@w3.org > June 2003

[Minutes] 16 Jun 2003 TAG teleconf (Arch Doc, contentTypeOverride-24)

From: Ian B. Jacobs <ij@w3.org>
Date: 17 Jun 2003 15:50:36 -0400
To: www-tag@w3.org
Message-Id: <1055879436.2582.221.camel@seabright>

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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:32:38 UTC