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

[Minutes] 12 May 2003 TAG teleconf (Voice WG about contentTypeOverride-24)

From: Ian B. Jacobs <ij@w3.org>
Date: 12 May 2003 18:36:30 -0400
To: www-tag@w3.org
Message-Id: <1052778989.18532.294.camel@seabright>

Hello,

Minutes from the 12 May 2003 TAG teleconference
with the Voice WG are available as HTML [1] and
as text below.

Corrections welcome. Thank you,

 _ Ian

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

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

                   Minutes of 12 May 2003 TAG teleconference

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

      [4] http://www.w3.org/2003/05/12-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 (45min)

    1. Roll call: From TAG: SW (Chair), TBL, DC, TB, RF, CL, PC, NW, IJ.
       For discussion with Voice WG, DO present. From Voice WG: Scott
       McGlashan, Jerry Carter, Brad Porter, Dan Burnett, David Burke,
       Max Froumentin
    2. Accepted [8]5 May teleconference minutes
    3. Accepted this [9]agenda
    4. Next meeting: 2 June [19 June people at AC meeting, 26 May is a
       holiday in UK/US/Canada].

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

  1.1 Meeting planning

     * TAG virtual meetings 2 and 19 June (no meeting 16 June). See
       [10]comments from Stuart.

     [10] http://lists.w3.org/Archives/Member/tag/2003May/0009.html

   SW: I think we should focus on the arch doc at the 2 June meeting.
   PC: There are two kinds of analysis we could do in walking through the
   document. Things that people don't agree with.

  1.2 W3C Track Presentation

     * Action PC 2003/04/14: Propose TAG's [11]WWW2003 track report to
       TAG.

     [11] http://www2003.org/t_www.htm

   The TAG expects to discuss the report by email.

  1.3 TAG report at AC meeting

    1. [12]Suggestions for TAG presentation at May AC Meeting from DO and
       PC
    2. Action DO, CL: Present TAG's AC meeting report to TAG.

     [12] http://lists.w3.org/Archives/Member/tag/2003Apr/0027.html

   The TAG expects to discuss the presentation/slides by email.

   [Ian]

          See [13]comments from David to TAG
          CL: Important issues that are slowing us down
          [On httpRange-14]
          SW: TimBL and RF have you made progress on your discussions on
          httpRange-14?
          RF: Haven't discussed since Irvine face to face meeting. I've
          been working on RFC2396, focusing on being able to answer
          questions there.
          [On IRI spec]
          RF: At IETF meeting, I thought that we had made a decision. But
          Martin re-opened it in light of TAG discussion.
          PC: I think the TAG should report the collateral work that's
          going on (e.g., working with IETF)
          RF: Definitely We are updating the primary specs of the Web in
          response to some of the issues that have been raised/addressed.
          We removed registered name production from the syntax in
          RFC2396. All of the names we were using were DNS anyway. That
          was interfering with IRIs ability to know SCRIBE MISSED]. ]
          That was an obstacle to IRI-URI-IRI conversion.
          TBL: The TAG's primary issue (remaining) has to do with the
          namespaces spec.
          CL: Other issues holding us up: Comparison of URIs.
          PC: IRI-Everywhere precedence: RFC2396, IRI spec, then other
          specs can then refer to it. Dependencies among specs seems to
          be a good thing to bring up.
          CL: Before RFC2396, add IDNS. First half of slides would be to:

     [13] http://lists.w3.org/Archives/Member/tag/2003May/0029.html

         1. introduce TAG
         2. TAG generalities
         3. New issues since last 6 months.
         4. Issues closed, declined, or pending since last 6 months.

          PC: What about RDDL progress?
          TB: I'm behind on this. What needs to happen is (1) TB needs to
          clean up document. (2) PC needs to write up finding.

   [timbl_]
          I commend Tim Bray on his blog on iTunes and WWW architecture.

   [Ian]
          TB: Issue of how to turn RDDL into RDF needs to be solved. If I
          commit to do this by the end of this month...
          PC: Agreement to publication of RDDL as Note, then ask AC what
          to do. Report to AC that we are behind schedule. I'd suggest
          adding namespaceDocument-8 to list of issues to discuss; ask
          for feedback from AC on what to do with a RDDL Note. Important
          question for me is: "How to proceed with RDDL Note? What model
          to use?"
          SW: Another piece of work we've stalled on is xlinkScope-23.
          TB: Reminder, we agreed that, since sufficient interest, that
          we would agree to revisit the issue and express our technical
          opinion again.
          IJ: I read recent XHTML 2.0 draft, section 12.1 on linking. No
          HLink; just a comment about the HTML WG following work in this
          area.
          PC: I think we'd be delinquent not to have xlink-23 on our
          list. "Further work pending ....." So for me important issues
          are: IRI, HTTPRange, namespace 8, xlinkScope-23. I am concerned
          about asking question of last call to AC....
          TBL: I'm concerned about the question regarding last call.
          E.g., I feel that we address everything that's happened, not
          restraining ourselves to things that happened 2 years before we
          started. Reasonable to ask us to publish what we the TAG have
          now. But I don't want us to be constrained to just old stuff;
          people are asking us all the time how Web Services fit with the
          Web Architecture; we need to address that. If we talk about a
          service-oriented Web and a REST-oriented Web, to talk about one
          without the other is crazy. The document should at least make
          the distinction. Sem Web / Web Services are not out-of-scope.
          The issue of httpRange-14 cannot be resolved without
          considering the Semantic Web. I don't think we will have done
          the world a favor if we publish something that doesn't take
          into account Sem Web / Web Services.
          RF: I have no problem with that; it's easier for me if we are
          talking about the future Web as well. Then I can bring it all
          together in the description.
          PC: We could produce a last call document this fall, but it
          would largely be focused on Web today, and weak in other areas.
          We could ask the AC whether we could take that to Rec with such
          a weakness, or should rather fix before we go to Rec.
          CL: Right, to what extent is it modular?
          IJ: I agree with PC in that, like the Process Doc, it may be a
          rolling document. I think we should think about reporting less
          to the AC now, and in June addressing the question of last call
          in more detail.

2. Technical (45min)

    1. [14]contentTypeOverride-24

  2.1 [15]contentTypeOverride-24

   The TAG and Voice Browser Working Group are meeting this week to
   discuss this issue.
     * [16]contentTypeOverride-24
          + See finding "[17]Client handling of MIME headers"
          + Completed action IJ: Send email to the Voice Browser WG
          + About: [18]Speech Recognition Grammar Specification (SRGS)
            Version 1.0, section [19]2.2.2 External Reference by URI

     [16] http://www.w3.org/2001/tag/open-summary.html#contentTypeOverride-24
     [17] http://www.w3.org/2001/tag/doc/mime-respect.html
     [18] http://www.w3.org/TR/speech-grammar/
     [19] http://www.w3.org/TR/speech-grammar/#S2.2.2

   [Ian]
          SM: I'd like to give the background of how the Voice WG got to
          where it is. See also [20]background email from SM
          [History: Those present agree to leave history out of public
          record.]
          Now looking at:
          [21]http://lists.w3.org/Archives/Public/www-voice/2003JanMar/00
          62.html
          SM: There are cases where there's a mismatch between the "type"
          attribute value and the server config. See also precedence in
          SMIL spec.
          [Question of whether SVG does the same thing]
          SM: Question of proper server configurations

     [20] http://lists.w3.org/Archives/Member/tag/2003May/0012.html
     [21] http://lists.w3.org/Archives/Public/www-voice/2003JanMar/0062.html

   [Chris]
          or perhaps, standardisable server config so authoring tools can
          help out

   [Ian]
          SM: We modified the spec in a not-yet-published draft to say
          that (1) the protocol override only takes place when the media
          type returned by the server is not recognized by the grammar
          processor as a recognized grammar type. We'd like architectural
          consistency, but need to address real-world server
          misconfigurations.
          TBL: What about the type application/xml?
          SM: That means nothing to a grammar processor.
          TB: Is there a registered mime type?
          SM: We are in the process of registering three "+xml" types..
          TB: It seems to me to fair to say that this problem is not
          unique to this activity. Hints appear as far back as HTML. Is
          there some way in which this problem is unique to your
          application?
          SM: I think you are right, this is a general problem. One thing
          that is special is that the grammar processor is not
          necessarily a user agent; it can be a background process.
          CL: So there may not be a way to consult the user.......
          SM: Right, consulting the user may not make a lot of sense.
          {Scribe missed comment from Jerry Carter here}
          TB to RF: I have heard people say that disregarding media types
          may have substantial security implications. I think the finding
          should say more about the security issues.
          RF: The way that systems work for filtering content through
          enterprises: processing meta information and processing
          content. You can either take the approach that meta information
          is advisory, or that where the meta information disagrees with
          the information in the message is a trust breach. Thus, there
          are issues of trust and efficiency.
          SM: What components enforce this policy [when there's a
          mismatch between representation and metadata that was
          declared]?

   [timbl]
          (RF: .... and so when there is a mismatch you can block the
          data)

   [Ian]
          RF: That's simply a possibility the software can take to avoid
          trust issues. The processor could also examine all content and
          throw away bad stuff. If you don't tell the system what you're
          doing with the information, you run into issues of whether the
          content is to processed as part of your grammar. The user agent
          that's following the reference can distinguish the two, but
          intermediaries can't.
          BP: To see whether I get this, let's consider example of proxy.
          Suppose Flash content has security breach. You want to disable
          entry of flash content into the network. You don't want someone
          to be able to put up a Web page that references flash content
          and that overrides the security filter. The place where people
          in the middle can't do anything is by using HTTPS.
          CL: Suppose you have a document with Japanese mislabeled as
          text/plain, and an intermediary does the wrong thing with it
          due to misinterpretation of mime type.
          TB: [On dealing with poorly configured Web servers] I
          understand the problem, but I'm nervous about what you want to
          do.

         1. This application (voice browser) is not unique in having this
            problem
         2. Efficiency gains by being able to dispatch reliably on media
            type (rather than look into content) is huge [especially for
            busy servers]. Thus, potential efficiency losses are pretty
            severe.
         3. There is a new rubric of software (Web services security)
            where there will be a high volume of messages exchanged.

          TB: To work properly, this will rely on servers labeling things
          in a standards-conformant way. I don't think there's much
          benefit for working around a few misconfigured servers.
          SM: I think, in an ideal world, we'd like this. Whose authority
          do you take, the author or the server manager?

   [Zakim]
          timbl, you wanted to mention another example of security
          breach, in which a file is made which is valid under two
          grammars. and to say that on a larger scale allowing override
          is architecturally a very bad precedent.

   [Ian]
          TBL: The Web architecture says whose the authority over the
          URI. A combination of host manager and author. There's a
          private arrangement between the two. The "publisher"
          (combination of two) is authoritative. It's damaging to change
          that. To go this way, in the long term, is damaging because it
          undermines the URI as a singleton. You would end up needing a
          pair everywhere. We have to defend this fundamental arch
          principles.

   [timbl]
          1) it is early days now - new mime types to become known with
          time. it will get better. 2) One can do stuff in the meantime -
          dispatching on XML namespace is architecturally very sound.

   [Ian]
          TBL: After a while, people will fix their servers to serve the
          right media type, if not immediately. So the question is: How
          can we fix the short term problem?

   [Chris]
          out of the box servers know about PNG (after7 years!) but not
          svg, yet ...

   [TBray]
          Apache 2 out of the box has SVG I think

   [Chris]
          cool

   [Ian]
          TBL: It is sound to look at the toplevel namespace.
          SM: That's where the authority of the author is encoded.

   [Chris]
          authority of author (ns decls) as opposed to server

   [Ian]
          SM: I'm not talking about general snooping; just a real
          representation of the author's intention.
          TBL: But it connects completely if you can get your host to
          send a .xml as "application/xml"; in that case it's ok to peak
          into it.
          TB: Even though it's less efficient. Don't start up an xml
          parser for every xml message that comes through.

   [Zakim]
          Chris, you wanted to say this is the passive labelling vs
          active processing model dilemma and to talk instead about how
          unstandardised control of labelling metadata is the real issue.

   [Ian]
          CL: There is no standardized way for author to locally set up
          server for a particular representation. If there were a
          standardized way to do this (here's my data and my metadata),
          then authoring tools could do the right thing. A kind of
          standardized ".htaccess" file.

   [Chris]
          we seem to be agreeing its ok to peek at ns in application/xml
          to figure out what it is

   [Ian]
          TBL: Looking at namespace is possible short-term solution. Can
          be used for new applications, and also small apps that don't
          want to register mime type.

   [Chris]
          that relates to xmlfunctions-34

   [Ian]
          BP: I see a general trend in this conversation - not just
          whether protocol designation is authoritative relative to
          client, but also whether object itself is authoritative (v.
          server message).
          TBL: The Web architecture is not designed that way - the
          content type is authoritative.
          SM: Whose authority is definitive?
          DC: The client can't distinguish through bits the author v. the
          server manager. In many cases, the conflict is not observable.
          If you say plain text at the top, and the document is xml, then
          that is also plain text. The server is right by definition; you
          can't detect the conflict on the client-side in the general
          case.
          JC: If you use other protocols, you won't get content type.
          There's a reality that you will need a backup in some cases.
          Whether you want to extend that to case where mime type is
          perceived as invalid is the open question.

   [Zakim]
          TBray, you wanted to agree with TimBL that it's inappropriate
          for user-agents to peek&guess

   [Ian]
          TB: Previously damaging behavior was by one browser that peeked
          inside HTML, overriding MIME type. There are improperly
          configured servers. I think that if you look at the finding, it
          says that what's not ok is to silently work around the
          unexpected media type.
          PC: So how does the client complain?
          TB: Can you preface to the person listing that there's a config
          problem?
          BP: In the voice xml case, the user is not necessarily in
          control of the configuration of their client. Another point: by
          saying that the protocol designation is authoritative, we are
          implying that application/xml is only ok for general case; but
          each vocab that has it's own processing model should have its
          own more specific type.
          TBL: I disagree a little; e.g., test applications.

   [DaveO]
          One problem with looking at the namespace name is it doesn't
          cover cases where the top element isn't the "owning" element,
          i.e., an xslt style sheet that is an xhtml template and the
          xslt is embedded within.

   [Ian]
          TBL: I think that there will be a lot of software that
          dispatches on namespace.
          TB: You only do that when you don't have a usable media type.
          Dispatching on namespace is more expensive than dispatching on
          mime type.
          IJ: What are scenarios where the user don't have any input
          opportunities?
          BP: Voice browser we implement doesn't have personal profile
          for caller. There are cookies for a given call (some config
          possible on a per-call basis), but not configuration across
          multiple calls. So problem of persistence across sessions.
          [Issues of processing, jumping out of dialog, then back in]
          JC: I'd like to go back to dispatch discussion. I agree that
          dispatch on namespace is more costly. We are trying to
          introduce a level between server media type and namespace that
          is supplied by the author.
          TBL: I don't think we should not ask the user to guide
          correction. Are we talking about guessing across XML or
          guessing about something that is not XML.

   [Zakim]
          timbl, you wanted to say asking the user is not an option we
          should waste our time over IMHO.

   [DanC]
          TimBL said he didn't want to discuss it, not the he didn't want
          it to happen (user correction)

   [Ian]
          JC: In deployed systems, we see 2 cases: either XML v. plain
          text OR raw octet stream v. proprietary grammar format.

   [Brad]
          want to acknowledge JC's earlier comments that breaking call
          flow to ask this question is not easy UI task for voice
          environment

   [Ian]
          [TBL suggests a security hack whereby content means one thing
          to one person and something else to another.]
          [E.g., when parsed per one spec, looks like a pizza order. When
          parsed by a more sophisticated parser, knows you are ordering a
          pizza + 20 years of life insurance.]
          TBL: You are not being consistent about one published meaning
          of the document.
          TB: Seems like we have shared appreciation of the issues
          (safer, sounder, more efficient to rely on media types). But I
          think the finding sets the right tone.
          SM: The spec attempts to provide a last resort fallback. How do
          you deal with the conflict in a voice-only scenario; you don't
          really have the opportunity to ask the user how to proceed.
          DC: People do things that are counter to specs. As a rule, we
          don't change the specs to accommodate this. Why should W3C
          accommodate this, unless we think they're doing something good?

   [Ian]
          IJ: I'd like to point out in finding that SMIL gets it wrong.
          And in general, I am listening here to figure out how the
          finding will evolve in light of this discussion.
          CL: One reason SMIL did this was due to newness of spec.
          RF: I don't agree with that at all. At apache, people send us
          their mime types; we update the core list regularly. We update
          with stuff that's been registered. People say "We haven't
          gotten around to registering our MIME type."

   [Chris]
          and registration is hard. See five-year email archive about
          trying to register some types:
          http://www.geocrawler.com/archives/3/319/1994/

   [Ian]
          SM: Registration process is challenging in practice. Big issue
          was that we had to continue to apply pressure on registration
          folks.
          SW: In 2.2.2 (speech grammar), para 2, could you explain to us
          again the expected behavior.
          [DC excused]
          SW: I am confused by the exception sentences. Latest version is
          different -
          SM reads new text for that section in [22]Voice WG internal
          draft.]
          JC: Intent is that the media type in the document should take
          precedent over introspection.
          SM: The essence is that the use of the type attribute should be
          considered a last resort.
          TBL: The phrase "when the information is unusable to the user
          agent" is not well-defined. Something may be unusable for one
          agent but not another. When you introduce a new format for your
          grammar, it allows agents to get confused. If you produce
          another specification (e.g., SG17) and serve it as an SG17
          document, and somebody points to your document and says it's an
          SG2 document. It works when you test with your software, but
          some clients can't use it.
          [Scribe didn't get entire scenario]
          TBL: Grammar may have picked it up from a trust resource, and
          done the wrong thing as a result.
          IJ: I haven't understood whether this is really a UI issue. I
          don't understand the scenarios enough.
          SM: Fine to pop up a prompt when it's your browser, but
          different when it's not your user agent in a voice only case
          (which would destroy the intent of the voice-only interaction).
          BP: Consider also automated systems, where there are no user
          interface components.
          TBL: My understanding of the way these things will work, is,
          e.g., browsing Web site over cell phone, picking up new
          information. Don't ask technical questions of user.
          BP: Do people really understand what "REPOST FORM DATA" really
          means?
          SW: Even with override, the actual entity returned could not be
          a piece of voice grammar. What would happen then? In that case,
          it would generate an exception event (for the AUTHOR to
          handle). E.g., the author can terminate the call.
          SW: Why would that not also be a sensible way of handling this
          case? Is it just a question of frequency of likely occurrences?
          JC: In intermediate cases, yes.
          SM: Authors control documents but not often can't control the
          mime types that are being fed out.
          IJ: Is combination of (1) error-handling mechanism and (2)
          application/xml sufficient for short term?
          BP: Problem with error-handling mechanism is that it stops
          processing. We'd rather have processing continue when the
          grammar engine can use the content.
          SW: The more failure is tolerated in silence, the less one can
          address the fact that the servers are not producing the proper
          metadata. What we don't want to end up in, is a situation where
          we move forward with SRGS and then feel we are blocked later
          on.
          SM: We recognize that what is proposed is not perfectly in line
          with Web arch, but the WG thinks it's a reasonable compromise.
          SW: Difference between what apps do and what you write in
          specs.
          CL: But hiding things doesn't improve interoperability.
          IJ: Would it be possible to terminate transactions when
          misconfiguration occurs? (This is one possible way to handle
          the error. How the error is handled would depend on the
          context/application.)
          SM: Yes, that is a fallback scenario.
          IJ: Send back diagnostics.
          CL: Like an ATM - it just shuts down and says "Try another ATM"
          SM: Almost all voice platforms would log the recasting as a
          warning.
          CL: Does the spec say anything about logging?
          SM: I think we could add to the spec that there's an
          expectation that system log it.

     [22] http://lists.w3.org/Archives/Member/w3c-voice-wg/2003Apr/0136.html

   [Chris]
          expectation of logging clarifies the seriousness of the issue
          different expectation of timeliness to fix, in a corporate
          environment

   [Ian]
          IJ: proposal (1) use application/xml for early deployment. (2)
          In the spec, say that when mismatch occurs, don't recover
          silently from error. Depending on the application, an agent
          might, for example, prompt the user for how to proceed, or, in
          another (e.g., voice-only) setting, might terminate and log the
          transaction mishap.
          SM: Would it be permissible to continue without user
          permission, but logging?
          JC: The user and voice browser are separated by more distance;
          user not interacting with the browser. The issue of how you
          accept the message is in the domain of the browser maintainer.
          Something like: "Browser must be configurable to either proceed
          or return error."?
          IJ: How does grammar processor talk to browser?
          SM: Can happen in different ways.
          IJ: Two pieces: (1) grammar processor must signal error (2)
          browser needs to get user permission.
          JC: But that interrupts call flow.
          SM: I think that logging would be acceptable to Voice WG. I
          think the Voice WG would accept a req to inform provider of
          mismatch, even if agent allowed to proceed.
          IJ: Next step?
          SM: We'll discuss tomorrow at mtg. Depending on the meeting, we
          can have another discussion.
          SW: Perhaps at next meeting, poll TAG for individuals and when
          they would meet.

  2.2 Architecture document

   No discussion this week.

   See also: [23]findings.
    1. [24]26 Mar 2003 Working Draft of Arch Doc:
         1. Action DC 2003/01/27: write two pages on correct and
            incorrect application of REST to an actual web page design
         2. 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. Action DC 2003/03/17: : Write some text for interactions
            chapter of arch doc related to [25]message passing, a dual of
            shared state.

     [23] http://www.w3.org/2001/tag/findings
     [24] http://www.w3.org/TR/2003/WD-webarch-20030326/
     [25] http://lists.w3.org/Archives/Public/www-tag/2003Mar/0018.html

  2.3 Issues that have associated action items

     * [26]whenToUseGet-7
          + Completed action IJ 2003/05/05: Solicit review of [27]revised
            draft finding, after taking into account comments from DC.
            ([28]Done)
     * [29]uriMediaType-9
          + IANA appears to have responded to the spirit of this draft
            (see [30]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?]
     * [31]abstractComponentRefs-37
          + See [32]issue description from David Orchard
          + Next steps?
     * [33]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.
          + Action PC 2003/04/07: Prepare finding to answer this issue,
            pointing to the RDDL Note. See [34]comments from Paul
            regarding TB theses.
          + Action TB 2003/04/28: Draft a TAG opinion on the use of URNs
            for namespace names, for review by the TAG
               o RF: Folks assume that because the specs say so, URNs
                 will be persistent. But persistence is a function of
                 institutional commitment and frequency of use.
     * [35]xlinkScope-23
          + Status report?
          + See [36]draft, and [37]SW message to CG chairs.
     * [38]IRIEverywhere-27
          + Completed action TB 2003/04/14: Draft a proposed step forward
            on IRI 27. ([39]Done). In that [40]email, TB proposes to
            close this issue.
          + 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. Progress: See [41]email to
            TAG.
       [42]URIEquivalence-15
          + SW proposal: Track RFC2396bis where [43]Tim Bray text has
            been integrated. Comment within the IETF process. Move this
            issue to pending state.
     * [44]xmlIDSemantics-32
          + See [45]Chris Lilley draft finding.
            Action NW 2003/05/05: Point Core WG to CL finding once made
            public.
     * [46]siteData-36
          + Action TBL 2003/02/24 : Summarize siteData-36
     * [47]xmlFunctions-34
          + Action TBL 2003/02/06: State the issue with a reference to
            XML Core work. See [48]email from TimBL capturing some of the
            issues.
     * [49]binaryXML-30
          + Action TB 2003/02/17: Write to www-tag with his thoughts on
            adding to survey.
          + Next steps to finding? See [50]summary from Chris.
     * [51]contentPresentation-26
          + Action CL 2003/02/06: Create a draft finding in this space.
            Due 3 March.
     * [52]rdfmsQnameUriMapping-6
          + Action DC 2003/02/06: Propose TAG response to XML Schema
            desideratum ([53]RQ-23).
     * [54]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 [55]message from Larry Masinter w.r.t. Web services.
     * [56]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. Relation to [57]Client handling of MIME
            headers?
     * [58]metadataInURI-31
          + Action SW 2003/02/06: Draft finding for this one.
          + See also [59]TB email on Apple Music Store and use of URI
            schemes instead of headers
     * [60]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.

     [26] http://www.w3.org/2001/tag/ilist.html#whenToUseGet-7
     [27] http://www.w3.org/2001/tag/doc/get7-20020610.html
     [28] http://lists.w3.org/Archives/Public/www-tag/2003May/0051.html
     [29] http://www.w3.org/2001/tag/open-summary.html#uriMediaType-9
     [30] http://lists.w3.org/Archives/Public/www-tag/2003Feb/0302.html
     [31] http://www.w3.org/2003/05/24-tag-summary.html#abstractComponentRefs-37
     [32] http://lists.w3.org/Archives/Public/www-tag/2003Apr/0089.html
     [33] http://www.w3.org/2001/tag/open-summary.html#namespaceDocument-8
     [34] http://lists.w3.org/Archives/Member/tag/2003Apr/0046.html
     [35] http://www.w3.org/2001/tag/ilist.html#xlinkScope-23
     [36] http://lists.w3.org/Archives/Member/tag/2003Mar/0094.html
     [37] http://lists.w3.org/Archives/Member/tag/2003Mar/0104
     [38] http://www.w3.org/2001/tag/open-summary.html#IRIEverywhere-27
     [39] http://lists.w3.org/Archives/Public/www-tag/2003Apr/0090.html
     [40] http://lists.w3.org/Archives/Public/www-tag/2003Apr/0090.html
     [41] http://lists.w3.org/Archives/Member/tag/2003Apr/0074.html
     [42] http://www.w3.org/2001/tag/open-summary.html#URIEquivalence-15
     [43] http://www.textuality.com/tag/uri-comp-4
     [44] http://www.w3.org/2001/tag/ilist#xmlIDSemantics-32
     [45] http://www.w3.org/2001/tag/doc/xmlIDSemantics-32.html
     [46] http://www.w3.org/2001/tag/ilist.html#siteData-36
     [47] http://www.w3.org/2001/tag/ilist#xmlFunctions-34
     [48] http://lists.w3.org/Archives/Public/www-tag/2003Feb/0309.html
     [49] http://www.w3.org/2001/tag/open-summary.html#binaryXML-30
     [50] http://lists.w3.org/Archives/Public/www-tag/2003Feb/0224.html
     [51] http://www.w3.org/2001/tag/open-summary.html#contentPresentation-26
     [52] http://www.w3.org/2001/tag/open-summary.html#rdfmsQnameUriMapping-6
     [53] http://www.w3.org/TR/2003/WD-xmlschema-11-req-20030121/#N400183
     [54] http://www.w3.org/2001/tag/open-summary.html#HTTPSubstrate-16
     [55] http://lists.w3.org/Archives/Public/www-tag/2003Feb/0208.html
     [56] http://www.w3.org/2001/tag/open-summary.html#errorHandling-20
     [57] http://www.w3.org/2001/tag/doc/mime-respect.html
     [58] http://www.w3.org/2001/tag/open-summary.html#metadataInURI-31
     [59] http://lists.w3.org/Archives/Public/www-tag/2003Apr/0151.html
     [60] http://www.w3.org/2001/tag/ilist#fragmentInXML-28

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/05/12 22:30:56 $



-- 
Ian Jacobs (ij@w3.org)   http://www.w3.org/People/Jacobs
Tel:                     +1 718 260-9447
Received on Monday, 12 May 2003 18:36:35 GMT

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