[Minutes] 24 Mar 2003 TAG teleconference (arch doc, issues 8, 15, 24, abstractCompontentRefs-37 [new])


Minutes of the TAG's 24 Mar 2003 teleconference are 
available as HTML [1] and as text below.

 - Ian

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


                   Minutes of 24 Mar 2003 TAG teleconference

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

      [4] http://www.w3.org/2003/03/24-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, TB, DO, PC, RF, NW, IJ. Regrets: TBL,
    2. Accepted [8]17 Feb telecon minutes
    3. Accepted this [9]agenda?
    4. Next meeting: 31 March

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

  1.1 Meeting planning

     * The TAG will strive to organize a virtual meeting shortly after
       the WWW Conference.
       Action TBL 2003/03/17: Propose June dates (after 4 June). [Also,
       some willingness also to meet before May confs]
     * Resolved: TAG will meet face-to-face 14-15 Nov in Japan
       Action IJ: Add Japan ftf meeting to calendar
     * Upcoming discussions:
          + The TAG expects to discuss its [10]W3C track presentation
          + The TAG expects to discuss its presentation to the AC

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

  1.2 Mailing list management

     * Incorporate some [11]proposed text from Stuart Williams into the
       [12]tips on communicating with the TAG.
       Completed action IJ 2003/03/17: Incorporate said text. Then,
       action SW: Send msg to www-tag drawing people's attention to
       revised text. (Done by IJ's message?)
     * Create a new list (public-tag-announce) for announcements of
       meeting minutes, meeting summaries, findings, new issues, resolved
       issues, and drafts of architecture documents. The TAG confirmed
       that all mail will go to www-tag and special announcements to
       Completed action IJ 2003/03/17: Request list setup; update TAG
       home page. ([13]Done).
     * Action IJ: Announce creation of public-tag-announce to chairs and
       tech plenary participants.

     [11] http://lists.w3.org/Archives/Member/tag/2003Mar/0053.html
     [12] http://www.w3.org/2001/tag/#tag-attn
     [13] http://lists.w3.org/Archives/Public/www-tag/2003Mar/0047.html

2. Technical

    1. [14]abstractComponentRefs-37
    2. [15]Architecture Document
    3. [16]URIEquivalence-15
    4. [17]contentTypeOverride-24
    5. [18]namespaceDocument-8

  2.1 References to abstract components (abstractComponentRefs-37)

     * Paul summarized a message from Jonathan Marsh ([19]forwarded by
       Paul Cotton); related to [20]rdfmsQnameUriMapping-6. See also
       [21]email from Paul about schema component designators

     [19] http://lists.w3.org/Archives/Public/www-tag/2003Feb/0207.html
     [20] http://www.w3.org/2001/tag/ilist#rdfmsQnameUriMapping-6
     [21] http://lists.w3.org/Archives/Member/tag/2003Mar/0063.html

          "SCUD", nee "NUN"

          PC: Question as posed:
          > Is it wise to use fragment IDs for identifying abstract
          > within a namespace, even though it is the most natural and
          > mechanism? Is there another mechanism that would be
          PC: I believe that answer to this question would be germaine to
          the current XML Schema work on SCUDs.

          SCUD really sucks as a label

          DO: We talked about this in Hawaii. I explained that WSDL was
          going to use the namespace name for abstract pieces. I pointed
          out that if namespace names were to be used in this way, a
          number of outstanding questions, in particular double use of
          DC: How is this different from issues 6/14/8? See my message
          [22]"rdfmsQnameUriMapping-6 affects WSDL too"
          PC: How do we make progress?
          TB: I probably agree with DC that there's natural overlap with
          issue 6. I think we could subsume this under issue 6, and
          immediately talk about it. In particular, I think Jonathan is
          right - that the proposed approach is architecturally wrong.

     [22] http://lists.w3.org/Archives/Public/www-tag/2002Nov/0153.html

          (propose approach uses fragments/ #)

          DC: I disagree with TB.
          RF: Not sure that this is part of 6; 6 is about establishing an
          algorithm once you know the namespace. I agree it's related.
          DO: I tend to think that this is a new issue. This is about the
          relationship between use of a namespace name and frag ids.

          ok, well, that sounds like issue fragmentInXML-28 : Use of
          fragment identifiers in XML

          DC: My position on issue 14 is that using anything other than a
          hash for something that's not a document would be wrong.
          DO: This is close to 28. If we said that the WSDL id refers to
          the concrete thing as represented in a WSDL doc, then I'd agree
          that it's part of 28. But now it's abstract.
          SW: New issue?
          Yes: DO, NW, RF, PC, TB, SW
          No: DC

          Name: Definition of abstract components with namespace names
          and frag ids.

          Proposed: abstractComponents-37

          'abstractComponent' is ok by me

          Proposed: abstractComponentRefs-37


          IJ: I will use DO's title. I expect to use JM's example and
          question for the issue.
          DO: There are some subtleties. One thing you'll notice is that
          they are naming things. What they've done is say that names are
          context sensitive. E.g., an operation and interface could be
          the same names. So they came up with an algorithm. Some people
          in the WG said don't use name constract at all, use id and
          ensure that's unique. New frag id syntax which is
          WSDL-specific. Thought a lot about using alternative URI
          schemes (e.g., URNs): Ran into problem of using HTTP scheme but
          desire to use new frag id syntax.

          please link in
          to the issue

     [23] http://lists.w3.org/Archives/Public/www-tag/2003Jan/0148.html

          TB: I have a big problem with the actual example in JM's
          message. Seems deeply unsound to specify the use of a frag id
          unless you know what the media type of the representation will
          be. E.g., if you knew this was RDF, it would be easier to

          DanC, you wanted to suggest that if there are different
          namespaces, give each of them a different name

          DC: I like the way they've done it just fine. The general idiom
          is that the frag id is whatever it means when you look up the
          document. You might have three different MIME types where it
          means the same thing in all three.
          RF: The notion that identifiers identify documents is false.
          You can't use hierarchical syntax within the identifiers. The
          idea that it's an abstract namespace is false.

          ("false"? I think you mean you disagree, Roy.)

          False as in not real, no reflection of reality

          sure, there's plenty reflection in reality.

          RF: This is just basic names. No need to use a frag id in this
          case. This is just a namespace that's hierarchical. What you
          get back with GET is independent on allocation of names.
          DO to TB and RF: So let's assume that what they've done is
          bogus. What should they be doing?
          TB: I made suggestions:

         1. Specify what the media type is that you get when you
            dereference a WSDL namespace resource (removes ambiguity)
         2. Abandon frag syntax, go with straightforward hierarchical

          TB: Nobody has said what you'll get back from a GET. The
          semantics of what comes after "#" is really different in
          practical terms.

          clarifying what I said: the general idiom docName#doodadName
          means whatever doodadName means as used in docName

          DO: Let's assume that we agree that RDDL-foo is a good thing.
          What's the intersection with this question?
          TB: RDDL-foo will have a well-defined semantics for frag
          DO: Suppose they get back a RDDL-foo document; seems like
          there's a conflict between RDDL-foo frag syntax and WSDL
          identifier syntax. Imagine that I come up with a fragment that
          looks fine in WSDL but is also fine in the RDDL-foo document.
          E.g., "#message". What if this maps to an id in the RDDL-foo
          TB: This is an xpath on the WSDL document, isn't it?
          PC: Close. It's a sufficient path to identify the local named
          TB: Seems like it's a frag id that "would like to be
          interpreted w.r.t. the WSDL document".
          DO: What's the URI of the WSDL document? They'd like to use the
          namespace name; there may be N instances of a WSDL document.

          yeah! put WSDL documents at their namespace name.
          self-describing web!

          DO: The namespace name is the thing that binds them together;
          not the URI (which may point to something behind a firewall).
          TB: Seems like abuse of URI + frags.

          Dave's example that demonstrates the potential confusion that
          can arise when fragment identifiers are used as names where the
          media-type is unknown is exactly why I agree with Roy that
          these are just names and it really is architecturally
          problematic to use fragment identifiers as names.

          NW: Using fragids as names is making me uncomfortable. I'd be
          happy if we all agreed that this was a problem.
          DO: I think the WSDL WG would be fine with input from the TAG
          on this (either "fine" or "do this instead"). Not sufficient to
          just say "Wrong" with no counter-proposal.
          DC: I think it's natural to combine port names with wsdl
          namespace names, look them up and find a wsdl document that
          tells you about the port.

          DanC, you wanted to say that confusion can be cured either by
          changing tech. solutions or by un-confusing people

          [PC summarizes issues, requirements]
          TB: I agree that this is a real problem; not sufficient for TAG
          to just say "no" and go away. Does WSDL have an IANA media type
          registration in progress?
          PC: Don't know.
          DO: I think they plan on registrating a WSDL media type.
          TB: In RDDL discussions, idea had been floated once or twice
          that particular frag identifier semantics required: inclusion
          of pointers to other resources.

          namespace name#rddl piece (like WSDL)#WSDL frag id

          TB: Suppose you have namespace N. N comes with an xml schema
          and a wsdl document. I would like to have a way to do what
          these guys are doing - to point at something in a wsdl document
          when all I have in my hand is the namespace URI.

          (would be nice if ftf place names were included in
          [24]http://www.w3.org/2001/tag/#about so I could search on

     [24] http://www.w3.org/2001/tag/#about

          TB: You'd like to point into a document, and then a second
          fragment that identifies something referenced from that point.
          SW: Why is conventional hierarchical path a bad way to go?

          discussion in Hawaii of issue 8

     [25] http://www.w3.org/2002/11/18-tag-summary#RDDL

          In the CMS world, a compound hierarchical document is no
          different from a hierarchical directory system -- all names are
          hierarchies and the names are separated by "/" all the way down
          to the smallest atom of content. WSDL defines a compound
          document namespace rooted at its namespace URI. So, add a slash
          and define the hierarchy below the namespace URI according to


          content management system

          yes but Roy, how do you when you can do that?

          how do you know?

          PC: Xquery functions and operators document has a namespace,
          all functions assumed to be in that namespace. How do I
          identify one of the operators?

          I mean, how do you know to define the hierarchy according to
          WSDL as opposed to some other framework?

          With respect to what DanC said, the problem is that they aren't
          *names* if the meaning can change depending on what you
          actually happen to get back. Names and addresses aren't the
          same thing and fragids are part of an address. IMHO.

          NW: We'd make better progress if we had a way to use names
          independent of fragments.
          RF: I would replace the frag with the hierarchy under the WSDL
          syntax. They define a hierarchy. The namespace URI is a
          universal root. Can use a namespace hierarchy. The only time a
          frag should be used is when the client side of a situation is
          given the opportunity to adjust what the original identifier
          identified; that's not the case here.

          become ticketagent/message/listFlightsRequest?

     [26] http://airline.wsdl/ticketagent/#message(listFlightsRequest


          [27]http://airline.wsdl/? Do you mean

     [27] http://airline.wsdl/?
     [28] http://example.org/airline.wsdl/?

          this is *exactly* issue 14. How did anybody think it was

          What about ticketagent/message#listFlightsRequest?

          yes norm.

          TB: I think what IJ wrote would be just as uncomfortable.


     [29] http://airline.wsdl/ticketagent/message/listFlightsRequest

          DC: Names take on meaning by use. They DO take on meaning as a
          result of GET. You walk into a room and say "Dan". If I turn my
          head, that encourages you to associate the name "Dan" with me.
          RF: If I say to you "that's a red button" and you agree, then
          we've named that thing a red button.

          Context sensitive names are useful, but we're talking about
          context-insensitive names; names that are globally unique.

          DC: Yes.
          RF: So if we say that the namespace doc specifies a
          hierarchical namespace underneath the root identifier, then
          surely we've named them.
          TB: RF's proposal seems appealing on the surface. Seems to be
          consensus that people want to do this.
          PC: How do you know what the namespace is?
          TB: That's given.
          DC: You can't undo it, in general.
          TB: Yes.
          TB: The problem with that - suppose I have 3 different xml
          schemas for a namespace. You'd have different hiearchical
          fan-outs depending on which schema you're talking about.

          (being able to undo the combination of namespace name with
          localname (etc) is one of the desierata for issue 8)

          TB: Solution to problem - address one of your resources in your
          RDDL documen.t
          NW: I.e., add an indirection.
          DO summarizing:

         1. There'd be a URI that gives you a RDDL document, then
         2. # some section, then...

          [30]http://rddldocumenturl#wsdlsection/travelagent/message and
          so on?

     [30] http://rddldocumenturl/#wsdlsection/travelagent/message

          DO: I hear that use of # is not appropriate since it's not a
          fragment, it's an abstract thing. Also, I hear people saying
          "/" is fine for distinguishing namespace portion and conceptual
          TB: I'd like to squeeze the "#" out of the middle.

          DanC, you wanted to reply to know what to do with it just from
          the name

          DC to PC: In general, you don't know what a name means just be
          looking at it; you need more information about it.
          DC: I know that " knowing what to do with it just by looking at
          it" is *not* a requirement; it conflicts with the principle of
          URI opacity. I need to think about this before agreeing to
          DO: There is another solution - don't define things abstractly.
          If you are going to define things in WSDL, use the frag id
          syntax - if you want to talk about something name pieces of
          your wsdl documents.

          I need to think about #-less proposal before agreeing to them.

          DC: You shouldn't define things by their syntax. A message is a
          message. WSDL should be able to specify messages and it should
          be possible to have other syntaxes.
          TB: I thought I heard some agreement around the following:

         1. People think that what the WSDL WG is trying to do is
            reasonable in starting with a namespace name as a basis for
         2. Reasonable to want to have a hierarchical naming scheme in
            their conceptual framework.
         3. Seems reasonable to want to tie this together in a URI

          TB: At least some of us have grave concerns about use of "#" in
          the originally presented example (flies in the face of RFC
          2396). Therefore, the TAG and interested parties need to find a
          way to achieve these worthy objectives.
          DC: It seems to me to be more cost effective to say "don't use
          the same name to name 2 different things."
          [DC suggests that he needs to reflect offline]
          TB: Will work in this area also help us with schemas?
          DC: Yes, this is issue 6/14/8!

          I can volunteer

          Action TB: Summarize TB's opinion on this discussion and
          relation to other issues.
          Resolved: DO is owner of new issue
          DO: I'd like range of possible solutions indicated.
          PC suggests that DO does so by responding to TB's post.
          DC: I still intend to respond on issue 6.

  2.2 Architecture document

   See also: [31]findings.
    1. [32]21 Mar 2003 Editor's Draft of Arch Doc:
         1. Completed action IJ 2003/03/17: Draft a new hybrid that
            incorporates intro of 6 Feb draft into 21 Feb version.
         2. Action DC 2003/02/06: Attempt a redrafting of 1st para under
            [33]2.2.4 of 6 Feb 2003 draft
         3. Action DC 2003/01/27: write two pages on correct and
            incorrect application of REST to an actual web page design
            DC: Some progress.
         4. 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.
         5. Action CL 2003/0127: Draft language for arch doc that takes
            language from internet media type registration, propose for
            arch doc, include sentiment of TB's second sentence from
         6. Withdrawn action TB 2003/01/27: Develop CP11 more: Avoid
            designing new protocols if you can accomplish what you want
            with HTTP. DC suggested describing GET/PUT/POST in a para
            each, then say "if your app looks like that, use HTTP".
            [34]Proposal from TB to withdraw the proposal.
         7. Action DC 2003/03/17: : Write some text for interactions
            chapter of arch doc related to [35]message passing, a dual of
            shared state.
         8. See [36]PC's email on feedback from Tech Plenary; see also
            [37]minutes of TAG session at Tech Plenary
            The TAG thanks Susan Lesch for good minutes!

     [31] http://www.w3.org/2001/tag/findings
     [32] http://www.w3.org/2001/tag/2003/webarch-20030321
     [33] http://www.w3.org/2001/tag/2002/webarch-20030206#uri-use
     [34] http://lists.w3.org/Archives/Public/www-tag/2003Feb/0005
     [35] http://lists.w3.org/Archives/Public/www-tag/2003Mar/0018.html
     [36] http://lists.w3.org/Archives/Member/tag/2003Mar/0050.html
     [37] http://www.w3.org/2003/03/Plenary-Minutes.html#Session3


          (I apologized for not doing my bit on issue 6 yet, didn't I? If
          not, I hereby do so.)

          BTW, I was totally wrong about the location for where I did the
          whiteboard on wsdl's use of namespace names. It was boston, not
          hawaii. How I confused the 2 locations, I have no idea.

     [38] http://www.w3.org/2002/11/18-tag-summary#RDDL

          at a glance, new intro looks good

          IJ Two questions:

         1. Leave scenario up front?
         2. end this doc to TR page?

          DC: At a glance, I like the new intro
          TB: I think this is good. I have some nits, though. I'm a
          little embarassed about lack of progress on rest of document,
          RF, PC: Publish

          I could live without the "1. Starting with a URI" bit. It's
          abstract. I could live with going straight to the concrete
          scenario. but I can live with 5 lines of (what I consider)
          inessential stuff.

          TB, RF, SW: I think that "About this doc" is a bit far from the

          I could live with putting "about this document" in the SOTD.

          TB: How about losing the summary of points?
          [Agreement that the list is handy for navigation purposes]
          TB: Propose to move summary of principles in TOC. Work right
          into the flow of relevant sections.

          next time plus one

          IJ will record TAG's suggestions for draft after this TR page

          I don't mind a resolution to publish; I just noted we don't
          need one, having decided last week.

          DC: On behalf of URI CG, when are we going to last call? If
          it's different from June, please notify me.

   TAG agrees to request publication of 21 Mar draft.

  2.3 URIEquivalence-15

   [39]Issue URIEquivalence-15.
     * Completed action TBL 2003/01/20: Send email to uri@w3.org
       requesting terminology change (regarding definition of "URI").

     [39] http://www.w3.org/2001/tag/ilist.html#URIEquivalence-15
     [40] http://lists.w3.org/Archives/Public/uri/2003Jan/0005.html

          DC: I'm particularly interested in IRIEverywhere and
          RF: We had [41]URI meeting at IETF meeting. I presented on
          issues related to URI spec. Feedback about creating a URI BNF
          element was that it would be confusing.

     [41] http://www.ietf.org/ietf/03mar/uribof.txt

          # [42]summary of URI BOF meeting Larry Masinter (Fri, Mar 21

     [42] http://lists.w3.org/Archives/Public/uri/2003Mar/0037.html

          RF: Not much feedback or suggestions for better terminology.:
          On MD's IRI - pretty much consensus in the room that IRIs not
          contain delimiters of URIs.
          [IJ wonders whether this means that special meaning will be
          same in both IRIs and URIs]
          RF: For URI spec, we expect go to last call sometime end of
          June. Progress of IRI spec depends on URI spec.
          TB: Aren't we done with URIEquivalence? RF has already taken up
          text ([43]draft 4 from Tim Bray).

     [43] http://www.textuality.com/tag/uri-comp-4.html

          (reviewing records of

     [44] http://www.w3.org/2001/tag/ilist#URIEquivalence-15

          SW: Are we expecting a finding of URI Equivalence?
          TB: When it showed up in 2396bis, I thought that was
          RF: Yes, I think that's best.
          TB Proposal: Close URIEquivalence-15; TAG has proposed text
          that has been incorporated in an IETF draft. People should
          write to authors of that draft.
          DC: Do we have sufficient trust in handing it off? Are we
          endorsing existing IETF draft or ultimate RFC?
          RF: Is an endorsement necessary?
          DC: Our records should include an answer to that question.
          Action SW, PC: Review [45]IETF draft to see whether text
          satisfies URIEquivalence-15.

     [45] http://www.apache.org/~fielding/uri/rev-2002/rfc2396bis.html

  2.4 contentTypeOverride-24

     * [46]contentTypeOverride-24
          + See email from DC: [47]Fwd: link metadata cannot override
            server media type. Does this resolve this issue?

     [46] http://www.w3.org/2001/tag/open-summary.html#contentTypeOverride-24
     [47] http://lists.w3.org/Archives/Public/www-tag/2003Feb/0085.html

          DC: The server gets to say what the media type is. The document
          can't override what the server says.: SMIL 2 spec also has
          this. That Rec has a similar bug in it. Apologies. I suggested
          that, like HTML docs, to use hints. They responded that server
          managers or servers don't get this right. They've come back
          since then with an intermediate position (i.e., when server is
          clearly misconfigured). I still can't agree to it.
          IJ: Tie-in to Xinclude coercion of media type.
          DC: "What the server says is right, even if the server is
          misconfigured. Don't mask bugs.": But the problem with my
          position is that it's pushing water uphill.
          TB: This is not just theology. This kind of sniffing almost
          always leads to bad results.
          IJ: I thought CL had an action on this w.r.t. errorHandling-20.


     [48] http://www.w3.org/2001/tag/2002/0129-mime.html#consistency

          TB: I got hosed by browsers, when CSS isn't served as text/css.
          Some browsers silently mask bad server behavior. Hard to find
          the source of a problem.
          RF: Problem is browsers that don't obey specs.

          Problem is that this draft spec is going to *mandate* not
          obeying the spec

          Agreement with DC's email to Voice Browser WG: TB, NW, SW, DC,
          PC, DO
          DC: My message didn't say much about why. We need to provide
          rationale. TB just told us why it's not right.
          Action IJ: Draft up some language; make connection to
          error-handling issue. TAG position with rationale why to not
          override server value of content type.

  2.5 namespaceDocument-8

     * [49]namespaceDocument-8
          + Next steps on [50]RDDL Proposal from Tim Bray/Paul Cotton
          + "[51]Resource Directory Description Language (RDDL)" (14 Feb
            2003 draft)

     [49] http://www.w3.org/2001/tag/open-summary.html#namespaceDocument-8
     [50] http://lists.w3.org/Archives/Public/www-tag/2003Feb/0213
     [51] http://www.textuality.com/xml/rddl3.html

          TB: We may need TBL for this one.

          See [52]discussion at 17 Feb meeting

     [52] http://www.w3.org/2003/02/17-tag-summary.html

          DC: One objection I had - doesn't talk about modularization.
          TB: This hasn't been fixed.
          DC: It's not acceptable as is because it suggests that you
          build invalid HTML documents.
          [DO drops off]
          DC: I think this is something of a minor point; but in general
          I'm less interested in HTML solutions than RDF solutions
          TB: How do you solve the HTML problem?
          DC: Different DOCTYPE (see HTML Modularization spec)
          TB: Jonathan did that for a previous version...
          [Discussion of what to do with this document.]
          TB: I propose that, if we agree to the content of the proposal
          (modulo objection from DC), that this be put on the Rec track.

          (my comment about DTD validity seems to be unminuted)

          DC: For me to agree to proposal, it has to say that this spec
          is not the only option and that RDF and XML Schemas are
          examples of other options
          TB and DC disagree on whether XML Schema - as -namespace doc is
          bad idea or reasonable idea.
          SW: I am reticent about whether TAG chartered to put this kind
          of doc on Rec track.
          DC: Would an AC rep be annoyed at TAG doing this, where there
          was no normal CFP?
          [SW, PC agree that this is sensitive]

  2.6 Issues that have associated action items

     * [53]xmlIDSemantics-32
          + Status of Chris Lilley draft finding in this area? See
            [54]early snapshot from CL
     * [55]IRIEverywhere-27
          + Action CL/IJ 2003/03/17: Send edited piece that CL/MD/IJ
            wrote to www-tag. Deadline 24 Mar. CL expects at following
            TAG mtg
     * [56]siteData-36
          + Action TBL 2003/02/24 : Summarize siteData-36
     * [57]xmlFunctions-34
          + Action TBL 2003/02/06: State the issue with a reference to
            XML Core work. See [58]email from TimBL capturing some of the
     * [59]binaryXML-30
          + Action TB 2003/02/17: Write to www-tag with his thoughts on
            adding to survey.
          + Next steps to finding? See [60]summary from Chris.
     * [61]contentPresentation-26
          + Action CL 2003/02/06: Create a draft finding in this space.
            Deadline 3 March.
     * [62]rdfmsQnameUriMapping-6
          + Action DC 2003/02/06: Propose TAG response to XML Schema
            desideratum ([63]RQ-23).
     * [64]uriMediaType-9
          + Action DC 2003/02/06: Start discussion on
            discuss@apps.ietf.org, but not urgent
     * [65]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 [66]message from Larry Masinter w.r.t. Web services.
     * [67]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. Deadline first week of March.
     * [68]metadataInURI-31
          + Action SW 2003/02/06: Draft finding for this one.
     * [69]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.

     [53] http://www.w3.org/2001/tag/ilist#xmlIDSemantics-32
     [54] http://lists.w3.org/Archives/Member/tag/2003Mar/0102.html
     [55] http://www.w3.org/2001/tag/open-summary.html#IRIEverywhere-27
     [56] http://www.w3.org/2001/tag/ilist.html#siteData-36
     [57] http://www.w3.org/2001/tag/ilist#xmlFunctions-34
     [58] http://lists.w3.org/Archives/Public/www-tag/2003Feb/0309.html
     [59] http://www.w3.org/2001/tag/open-summary.html#binaryXML-30
     [60] http://lists.w3.org/Archives/Public/www-tag/2003Feb/0224.html
     [61] http://www.w3.org/2001/tag/open-summary.html#contentPresentation-26
     [62] http://www.w3.org/2001/tag/open-summary.html#rdfmsQnameUriMapping-6
     [63] http://www.w3.org/TR/2003/WD-xmlschema-11-req-20030121/#N400183
     [64] http://www.w3.org/2001/tag/open-summary.html#uriMediaType-9
     [65] http://www.w3.org/2001/tag/open-summary.html#HTTPSubstrate-16
     [66] http://lists.w3.org/Archives/Public/www-tag/2003Feb/0208.html
     [67] http://www.w3.org/2001/tag/open-summary.html#errorHandling-20
     [68] http://www.w3.org/2001/tag/open-summary.html#metadataInURI-31
     [69] 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 is working with
       PLH on this. Revisit this end of April.


    Ian Jacobs for Stuart Williams and TimBL
    Last modified: $Date: 2003/03/25 16:16:34 $

Ian Jacobs (ij@w3.org)   http://www.w3.org/People/Jacobs
Tel:                     +1 718 260-9447

Received on Tuesday, 25 March 2003 11:41:37 UTC