W3C home > Mailing lists > Public > public-tag-announce@w3.org > July 2003

[Minutes] 7 Jul 2003 TAG teleconf (contentTypeOverride-24 (and Voice spec), whenToUseGet-7, metadataInURI-31)

From: Ian B. Jacobs <ij@w3.org>
Date: 07 Jul 2003 19:43:02 -0400
To: www-tag@w3.org
Message-Id: <1057621381.17044.123.camel@seabright>

Hello,

The minutes of the TAG's 7 July 2003 teleconf are available
as HTML [1] and as text below.

 - Ian

[1] http://www.w3.org/2003/07/07-tag-summary.html

============================================================

                   Minutes of 7 July 2003 TAG teleconference

   Nearby: [4]IRC log | |[5]Teleconference details  [6]issues list 
   [7]www-tag archive

      [4] http://www.w3.org/2003/07/07-tagmem-irc.html
      [5] http://www.w3.org/2001/tag/group/#remote
      [6] http://www.w3.org/2001/tag/ilist
      [7] http://lists.w3.org/Archives/Public/www-tag/

1. Administrative

    1. Roll call: SW (Chair), DC, DO, NW, TB, IJ (Scribe). For the
       discussion about contentTypeOverride-24, Jerry Carter from the
       Voice WG attended. Regrets: TBL, RF, PC. Missing: CL
    2. Tentatively accepted minutes of [8]30 Jun teleconference with
       changes requested by Chris Lilley. Awaiting confirmation from
       Chris Lilley.
    3. Accepted this [9]agenda
    4. Next meeting: 14 July. Likely regrets: NW.
    5. Face-to-face meeting agenda
       SW: I count on having an agenda for the TAG by next week.

      [8] http://www.w3.org/2003/06/30-tag-summary.html
      [9] http://www.w3.org/2003/07/07-tag.html

2. Technical

    1. [10]Review of text from Voice Browser Working Group and finding
       (contentTypeOverride-24)
    2. [11]Review of comments on finding for whenToUseGet-7
    3. [12]TAG comments on SW draft of finding for issue metadataInURI-31

     [12] http://www.w3.org/2003/07/07-tag-summary.html

  2.1 Review of text from Voice Browser Working Group (contentTypeOverride-24)

     * [13]contentTypeOverride-24
          + [14]Speech Recognition Grammar Specification Version 1.0,
            section [15]2.2.2 External Reference by URI
          + [16]Draft of revised text forwarded by Jerry Carter
            (Member-only)
          + Completed action SW 2003/06/23: Talk to Voice Browser WG
            about proposed text, then bring back to TAG. ([17]Done)

     [13] http://www.w3.org/2001/tag/open-summary.html#contentTypeOverride-24
     [14] http://www.w3.org/TR/speech-grammar/
     [15] http://www.w3.org/TR/speech-grammar/#S2.2.2
     [16] http://lists.w3.org/Archives/Member/tag/2003Jul/0026.html
     [17] http://lists.w3.org/Archives/Member/tag/2003Jul/0015.html

   [Ian]

          JC: Thanks to SW and IJ for discussions last week and for
          comments on text. One point in contention was use of "type"
          attribute overriding server headers. We've concluded that that
          was inappropriate and the new language makes the headers
          authoritative. We are taking a direction that the HTML WG seems
          to be going with XHTML 2.0: using "type" as a kind of
          preference (accept header). Once representation returned, if no
          header sent, then type serves as a strong hint. Most of SW/IJ
          comments have been incorporated. There are a few remaining
          minor issues open.
          TBray: Sounds like the results are clean and sensible. We
          should all be happy.
          [JC gives quick overview]
          TBray: Looks fine to me.
          DC: Please clarify the semantics of the table.
          JC: First three lines provide context; fourth line provides
          desired behavior.
          DC: Declared media type, if I understand, is some combination
          of server type and preferred type.
          IJ: I had initially said that dual usage of "type" was
          unnecessary; just use it as a preference.

   [TBray]
          I see potential editorial quibbles, but the thrust is
          architecturally sound, are we micro-managing?

   [Ian]
          IJ: But SW made a good point that it's cheaper to verify
          something's type than it is to determine the type of something.
          DC: I"m not comfortable with "alleged media type". I'd be most
          comfortable with a test case. You are headed for PR?
          JC: Yes, this is the only outstanding issue.
          DC: Do you have test cases for this behavior?
          JC: I think so. I would need to look at details. We have about
          200 tests. I believe there's a test for this; I"d have to be
          sure.
          DC: What would make me feel most comfortable is a test that
          shows a server returning text/plain and an implementation
          noticing the error.
          JC: That's a reasonable request. There are probably 2-3 tests
          one would run for this (i.e., each of the special cases).
          DC: It's not critical that the TAG endorse the final text. We
          were asked our opinion, we gave it, they tweaked their spec,
          and everybody's happy.
          JC: Outside of this discussion, I owe some personal feedback
          regarding test cases. But I think the issues between the Voice
          WG and the TAG are resolved.
          SW: I'd like to record our thanks to the Voice WG!
          TB, DC: Absolutely.
          The TAG wishes the Voice WG good luck!

   [JC leaves]

   More discussion on reviews of [18]Client handling of MIME headers
    1. Action CL, NW 2003/06/30: Read the draft finding by 7 July. [19]NW
       Done
    2. Completed action IJ 2003/06/30: Announce on www-tag that we expect
       to approve this finding in a week or so. Last chance for comments
       ([20]Done)
    3. Completed action IJ 2003/06/30: Ping SMIL IG about this finding,
       which refers to architectural error in SMIL 2.0 ([21]Done).
    4. See original [22]summary of comments
    5. [23]Comments from Norm Walsh
    6. See [24]comments from Philipp Hoschka and [25]comments from Rob
       Lanphier
    7. See [26]suggested editorial changes from TBL
    8. [27]Comments from Stuart Williams

     [18] http://www.w3.org/2001/tag/doc/mime-respect.html
     [19] http://lists.w3.org/Archives/Public/www-tag/2003Jul/0028.html
     [20] http://lists.w3.org/Archives/Public/www-tag/2003Jul/0002.html
     [21] http://lists.w3.org/Archives/Member/symm/2003Jul/0004.html
     [22] http://lists.w3.org/Archives/Public/www-tag/2003May/0099.html
     [23] http://lists.w3.org/Archives/Public/www-tag/2003Jul/0028.html
     [24] http://lists.w3.org/Archives/Member/tag/2003Jul/0005.html
     [25] http://lists.w3.org/Archives/Member/symm/2003Jul/0011.html
     [26] http://lists.w3.org/Archives/Public/www-tag/2003Jul/0020.html
     [27] http://lists.w3.org/Archives/Public/www-tag/2003Jul/0030.html

   [Ian]

          [28]Comments from Norm Walsh

     [28] http://lists.w3.org/Archives/Public/www-tag/2003Jul/0028.html

          NW: My comments were mostly editorial nits; fine on the whole.
          NW: In section 6, bullet 3, I would support "MUST NOT":
          "Specifications MAY include hints about server headers but
          SHOULD NOT include requirements that a client override these
          headers without involving the user."
          DC: Seems strange to constrain the spec. If you don't have the
          user's consent, you can't hold them responsible. I don't think
          this is the best advice we can give to spec writers .If a user
          agent wants to do something different than the published
          protocol, they have to do so with the consent of the user,
          otherwise they are not acting on behalf of the user.
          TBray: Any time somebody writes this sort of thing in a spec,
          they can be sure they'll get static from the TAG.
          DC: Will we read every spec? We can just say "The server mime
          type is authoritative."
          TBray: Then we should say nothing about what specs
          do..."SHOULD" is misleading.
          NW, DC: Change to MUST NOT in bullet 2.
          IJ: I can live without bullet 3 since section 5 covers this.

          Resolved: In section 6 of finding, drop bullet 3 and to change
          SHOULD NOT to MUST NOT in item 2.

          [29]Comments from Rob Lanphier

     [29] http://lists.w3.org/Archives/Member/symm/2003Jul/0011.html

          TBray: I think some of RL's comments about servers are useful,
          e.g., default content type is harmful.
          IJ: Seems like a reasonable addition to talk about how to
          address this issue in practice.
          DC: Don't talk about "harmful", talk about "risks of default
          content type" The right answer in case of misconfigured server
          is not to sweep it under the rug.

          [30]Suggested editorial changes from TBL

     [30] http://lists.w3.org/Archives/Public/www-tag/2003Jul/0020.html

          TBray: Unless TBL can provide some examples of the impact on
          programmers, what's the utility of this?
          DC: To me this look editorial and is not a huge improvement.
          Putting "the" in your face doesn't help things. I'd prefer that
          IJ return to TBL and ask for more motivation.
          TBray: I like TBL's example of showing how even self-describing
          content not sufficient (or may provide wrong info) about
          author's intent in some cases.
          Action IJ: Produce a new draft of the finding on MIME headers
          that takes into account comments from Rob Lanphier, TBL, NW, SW
          (editorial), and above resolution.

          [31]Comments from Stuart Williams

     [31] http://lists.w3.org/Archives/Public/www-tag/2003Jul/0030.html

          SW: I'd prefer "state of the resource" over "meaning of the
          resource". I think that "meaning of the resource" is more
          complex than its state. Also, the second security example
          didn't seem so credible to me.
          DC: "State" of the resource is ok.
          IJ: I'll produce a new draft for next week.

   [TBray]
          Ian: I think asked you to send a note to the SMIL folks saying
          "thanks, we're taking your input seriously & will redraft"
          Action IJ: Follow up with SYMM IG saying we'll take into
          account input and produce new draft of this finding.

  2.2 Review of comments on whenToUseGet-7 finding

     * [32]URIs, Addressability, and the use of HTTP GET and POST
          + [33]whenToUseGet-7
               o [34]Summary of comments
               o Action IJ 2003/06/23: Incorporate a sentence about scope
                 based on [35]comments from Larry Masinter

     [32] http://www.w3.org/2001/tag/doc/whenToUseGet-20030509.html
     [33] http://www.w3.org/2001/tag/ilist.html#whenToUseGet-7
     [34] http://lists.w3.org/Archives/Public/www-tag/2003May/0099.html
     [35] http://lists.w3.org/Archives/Public/www-tag/2003May/0104.html

   Summary of actions:
    1. Action DO: Send text that DO and Noah M. can agree to to
       tag@w3.org.
    2. Action IJ: Produce new draft of finding with (1) change based on
       LM comment, (2) text from DO/NM (3) don't address PUT in this
       finding, but add comment about new issue [36]putMediaType-38
       (second point in [37]summary of comments).

     [36] http://www.w3.org/2001/tag/ilist.html#putMediaType-38
     [37] http://lists.w3.org/Archives/Public/www-tag/2003May/0099.html

  2.3 TAG comments on SW draft of finding for issue metadataInURI-31

     * [38]metadataInURI-31
          + Completed action SW 2003/06/02: SW [39]4 July 2003 draft of
            finding
          + See also [40]TB email on Apple Music Store and use of URI
            schemes instead of headers

     [38] http://www.w3.org/2001/tag/open-summary.html#metadataInURI-31
     [39] http://www.w3.org/2001/tag/doc/metaDataInURI-31-20030704.html
     [40] http://lists.w3.org/Archives/Public/www-tag/2003Apr/0151.html

   [DanC]

          (hmm... no story atop [41]4 July 2003 draft of finding)

     [41] http://www.w3.org/2001/tag/doc/metaDataInURI-31-20030704.html

   [Ian]
          DC: I think the finding may be getting too long. I was hoping
          for three paras that say "Don't peek into URIs."
          "People and software making use of URIs assigned outside of
          their own authority (i.e. observers) MUST NOT attempt to infer
          properties of the referenced resource except as licensed by
          relevant normative specifications or by URI assignment policies
          published by the relevant URI assignment authority."
          SW: Can one make use of information published by W3C (in a
          policy)?
          DC: Shorten 3 to "Don't peek inside the URI." It's always safe
          to not peek inside the URI. On Scheme component designators and
          wsdl components....

   [DanC]
          the W3C tech reports naming policy isn't based on the URI
          alone. there's no guarantee that
          [42]http://www.w3.org/TR/2003/WD-snort-20040707 is a W3C
          working draft. If you know that it is a WD somehow, you can
          learn stuff from the URI. but you can never just peek into the
          URI alone.

     [42] http://www.w3.org/TR/2003/WD-snort-20040707

   [Ian]
          DO: DC's point (don't peek in URIs) is in conflict with what
          some groups are trying to do.
          SW: Does this draft need more work before sending to www-tag?
          DO: I agree with DC that it seems a little long.
          NW: If I understand DC correctly, sounds like DC is saying that
          if I know XQuery is a Working Draft, then I can find meaning in
          WD in URI. If I saw a URI ending in "WD-".... could I infer
          that it's a WD?
          DC: No You have to look at the TR page as well. Once you have
          found something on the TR page, there's quite a bit you can go
          on. If you start from the TR page and find the URI, that's
          fine. But if you find the URI on the floor somewhere, you can't
          go on that alone.

   [Norm]
          That [43]http://www.w3.org/TR/wd-foo exists does not imply foo
          is a WD unless and until it appears *as a link* on the TR page.

     [43] http://www.w3.org/TR/wd-foo

   [Ian]
          DC: Just don't peek in the URI.
          DO: I don't want the finding written that way.
          DC: A story would be useful. If you want to treat the entire
          topic, then start with a story. It's not clear why someone
          wants to read all this stuff. I don't think IJ is hot on the
          trail of a story. I don't think this comes up very often...may
          not deserve a real story.
          SW: I will take a crack at writing something short before
          floating on www-tag.
          NW: Perhaps DO could write a couple of paragraphs to motivate
          why one would want to do this.

   [DanC]
          which wsdl group posting?

   [Ian]
          DO: I'll write up something in response to SW's draft.
          DC: I'm not sure putting burden on SW is appropriate. Maybe
          just send what you've got and say there isn't agreement.
          Promote third bullet to abstract.
          DO: Amazon publishes policy for query parameters.
          DC: Perhaps cheapest approach is to open up to community.

   [DanC]
          treating the whole forms interface convention is more than I
          would have expected for a finding on issue metadataInURI-31

   [Ian]
          DO: Where do others stand on this?
          NW: I'm definitely on the fence. I think there's a lot of merit
          in "don't look inside the URI", but I understand what the WSDL
          WG wants to do.
          DC: Don't put version numbers in URIs was the original
          question.
          TBray: I think the answer is still "probably not"
          Action SW: Create new draft based on input today and send to
          www-tag.
          Action DO: Send rationale about why WSDL WG wants to peek
          inside the URI.

  2.4 Findings the TAG did not discuss

   See also: [44]findings.

     [44] http://www.w3.org/2001/tag/findings

   Next steps on these findings:
     * [45]xmlIDSemantics-32:
         1. [46]Chris Lilley draft finding.
         2. Action CL 2003/06/30: Revise this draft finding with new
            input from reviewers. 7 July Deadline.
     * [47]contentPresentation-26: Action CL 2003/06/02: Make available a
       draft finding on content/presentation.
     * Action IJ 2003/06/09: Turn [48]TB apple story into a finding.

     [45] http://www.w3.org/2001/tag/ilist#xmlIDSemantics-32
     [46] http://www.w3.org/2001/tag/doc/xmlIDSemantics-32.html
     [47] http://www.w3.org/2001/tag/open-summary.html#contentPresentation-26
     [48] http://www.tbray.org/ongoing/When/200x/2003/04/30/AppleWA

  2.3 Architecture document

   [49]27 June 2003 Working Draft of Arch Doc published.
    1. Discussion of [50]text sent by David Orchard about extensibility.
    2. Completed action PC 2003/06/16: Send second draft of AC
       announcement regarding TAG's last call expectations/thoughts and
       relation to AC meeting feedback ([51]Done).
    3. Action RF 2003/06/02: Rewrite section 5. Section 5 is expected to
       be short.
    4. Action IJ 2003/06/16: Attempt to incorporate relevant bits of
       "[52]Conversations and State" into section to be produced by RF.

     [49] http://www.w3.org/TR/2003/WD-webarch-20030627/
     [50] http://lists.w3.org/Archives/Public/www-tag/2003Jun/0086.html
     [51] http://lists.w3.org/Archives/Member/tag/2003Jul/0019.html
     [52] http://www.w3.org/DesignIssues/Conversations

   About [53]Paul's second draft of comments to AC.

     [53] http://lists.w3.org/Archives/Member/tag/2003Jul/0019.html

   [DanC]
          the question of who sends it to ac-forum is a good one

   [TBray]
          Issue is: who sends this thing, and to whom
          SW: want's TimBL's sign-off. I would want to sign it from both
          of us.

   [Ian]
          DC: Don't put TBL's signature at bottom of something he hasn't
          read.
          TBray: I propose that SW find TBL and get him to sign off.

   [TBray]
          Action SW: Try to get TimBL to sign off on Paul's text. If SW
          able to reach TBL, SW/TBL send to AC as co-chairs. If not, have
          IJ send on behalf of TAG.

   [DanC]
          so RESOLVED

  2.4 Issues the TAG did not discuss

     * [54]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.
     * [55]RDFinXHTML-35
     * [56]mixedUIXMLNamespace-33

     [54] http://www.w3.org/2001/tag/open-summary.html#errorHandling-20
     [55] http://www.w3.org/2001/tag/open-summary.html#RDFinXHTML-35
     [56] http://www.w3.org/2001/tag/open-summary.html#mixedUIXMLNamespace-33

  2.5 Issues with action items

     * [57]uriMediaType-9
          + IANA appears to have responded to the spirit of this draft
            (see [58]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?]
     * [59]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 [60]message from Larry Masinter w.r.t. Web services.
     * [61]xlinkScope-23
          + See [62]draft, and [63]SW message to CG chairs.
          + Action CL 2003/06/30: Ping the chairs of those groups asking
            for an update on xlinkScope-23.
     * [64]binaryXML-30
          + Action TB 2003/02/17: Write to www-tag with his thoughts on
            adding to survey.
          + Next steps to finding? See [65]summary from Chris.
     * [66]xmlFunctions-34
          + Action TBL 2003/02/06: State the issue with a reference to
            XML Core work. See [67]email from TimBL capturing some of the
            issues.
     * [68]siteData-36
          + Action TBL 2003/02/24 : Summarize siteData-36

     [57] http://www.w3.org/2001/tag/open-summary.html#uriMediaType-9
     [58] http://lists.w3.org/Archives/Public/www-tag/2003Feb/0302.html
     [59] http://www.w3.org/2001/tag/open-summary.html#HTTPSubstrate-16
     [60] http://lists.w3.org/Archives/Public/www-tag/2003Feb/0208.html
     [61] http://www.w3.org/2001/tag/ilist.html#xlinkScope-23
     [62] http://lists.w3.org/Archives/Member/tag/2003Mar/0094.html
     [63] http://lists.w3.org/Archives/Member/tag/2003Mar/0104
     [64] http://www.w3.org/2001/tag/open-summary.html#binaryXML-30
     [65] http://lists.w3.org/Archives/Public/www-tag/2003Feb/0224.html
     [66] http://www.w3.org/2001/tag/ilist#xmlFunctions-34
     [67] http://lists.w3.org/Archives/Public/www-tag/2003Feb/0309.html
     [68] http://www.w3.org/2001/tag/ilist.html#siteData-36

  2.6 Issues the TAG intends to discuss at face-to-face meeting

    Identifiers

     * [69]URIEquivalence-15
          + SW proposal: Track RFC2396bis where [70]Tim Bray text has
            been integrated. Comment within the IETF process. Move this
            issue to pending state.
     * [71]IRIEverywhere-27
          + Action CL 2003/04/07: Revised position statement on use of
            IRIs.
          + Action TBL 2003/04/28: Explain how existing specifications
            that handle IRIs are inconsistent. [72]TBL draft not yet
            available on www-tag.
          + See TB's[73]proposed step forward on IRI 27.

     [69] http://www.w3.org/2001/tag/open-summary.html#URIEquivalence-15
     [70] http://www.textuality.com/tag/uri-comp-4
     [71] http://www.w3.org/2001/tag/open-summary.html#IRIEverywhere-27
     [72] http://lists.w3.org/Archives/Member/tag/2003Apr/0074.html
     [73] http://lists.w3.org/Archives/Public/www-tag/2003Apr/0090.html

    Qnames, fragments, and media types

     * [74]rdfmsQnameUriMapping-6
          + Action DC 2003/02/06: Propose TAG response to XML Schema
            desideratum ([75]RQ-23).
     * [76]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.
     * [77]abstractComponentRefs-37
          + See [78]issue description from David Orchard. Next steps?
          + Action DO 2003/06/23: Point Jonathan Marsh at options. Ask
            them for their analysis.
     * [79]putMediaType-38

     [74] http://www.w3.org/2001/tag/open-summary.html#rdfmsQnameUriMapping-6
     [75] http://www.w3.org/TR/2003/WD-xmlschema-11-req-20030121/#N400183
     [76] http://www.w3.org/2001/tag/ilist#fragmentInXML-28
     [77] http://www.w3.org/2003/07/24-tag-summary.html#abstractComponentRefs-37
     [78] http://lists.w3.org/Archives/Public/www-tag/2003Apr/0089.html
     [79] http://www.w3.org/2001/tag/open-summary.html#putMediaType-38

    RDDL, namespace documents

     * [80]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 [81]1 June version.
          + Action PC 2003/04/07: Prepare finding to answer this issue,
            pointing to the RDDL Note. See [82]comments from Paul
            regarding TB theses.
          + Refer to draft TAG [83]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.

     [80] http://www.w3.org/2001/tag/open-summary.html#namespaceDocument-8
     [81] http://www.tbray.org/tag/rddl/rddl3.html
     [82] http://lists.w3.org/Archives/Member/tag/2003Apr/0046.html
     [83] http://lists.w3.org/Archives/Public/www-tag/2003Jun/0003.html

  2.7 New issues?

   The TAG expects to discuss these on 14 July.
    1. [84]Visibility of Web Services, raised by Mark Baker
    2. [85]Character model conformance, raised by TBL
    3. [86]Meaning of URIs in RDF documents, raised by TBL

     [84] http://lists.w3.org/Archives/Public/www-tag/2003May/0069.html
     [85] http://lists.w3.org/Archives/Public/www-tag/2003Jun/0009.html
     [86] http://lists.w3.org/Archives/Public/www-tag/2003Jul/0022.html

3. 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/07/07 23:33:41 $

-- 
Ian Jacobs (ij@w3.org)   http://www.w3.org/People/Jacobs
Tel:                     +1 718 260-9447
Received on Monday, 7 July 2003 19:43:14 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:17:58 GMT