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

[Minutes] 31 Mar 2003 TAG teleconference (Arch Doc, IRIEverywhere-27, URIEquivalence-15)

From: Ian B. Jacobs <ij@w3.org>
Date: 01 Apr 2003 11:37:41 -0500
To: www-tag@w3.org
Message-Id: <1049215060.1675.181.camel@seabright>


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

 - Ian

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


                   Minutes of 31 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/31-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: All present. SW (Chair), TBL, TB, DC, DO, PC, RF, CL,
       NW, IJ (Scribe)
    2. Accepted [8]24 Feb telecon minutes
    3. Accepted this [9]agenda
    4. Next meeting: 7 April. Regrets: SW. NW to Chair.
       Action IJ: Arrange for call to NW

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

  1.1 Meeting planning

     * The TAG will strive to organize a virtual meeting shortly after
       the WWW Conference. See [10]thoughts from SW on organizing a
       virtual meeting.
       Completed action TBL 2003/03/17: Propose June dates (after 4
       June). ([11]Done)
       Action TBL: Propose additional dates.
     * Completed Action IJ: Add Japan ftf meeting to calendar
     * Upcoming discussions:
          + The TAG expects to discuss its [12]W3C track presentation on
            7 April
          + The TAG expects to discuss its presentation to the AC on 14
            and 21 April.

     [10] http://lists.w3.org/Archives/Member/tag/2003Mar/0082.html
     [11] http://lists.w3.org/Archives/Member/tag/2003Mar/0111.html
     [12] http://www2003.org/t_www.htm

1.2 Mailing list management

     * Completed action IJ: Announce creation of public-tag-announce to
       chairs and tech plenary participants (and to AC).

2. Technical

    1. [13]Architecture document
    2. [14]IRIEverywhere-27 and [15]URIEquivalence-15

  2.1 Architecture document

   See also: [16]findings.
    1. [17]26 Mar 2003 Working Draft of Arch Doc:
         1. Action DC 2003/02/06: Attempt a redrafting of 1st para under
            [18]2.2.4 of 6 Feb 2003 draft.
            DC: No progress.
         2. Action DC 2003/01/27: write two pages on correct and
            incorrect application of REST to an actual web page design
            DC: Progress two weeks ago (found co-author).
         3. 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.
            DO: I am in meetings now on this topic. No indication of when
            this will be done.
         4. 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
            CL: This is about charset headers, and not generating them
            when they might be wrong. I hope to have something by next
         5. Action DC 2003/03/17: : Write some text for interactions
            chapter of arch doc related to [19]message passing, a dual of
            shared state.
            DC: I think I have some progress on latest one. This is my
            [20]scribbling on issue 8 and nearb[21]y. This is
            [22]scribbling on message passing as a dual of shared state

     [16] http://www.w3.org/2001/tag/findings
     [17] http://www.w3.org/TR/2003/WD-webarch-20030326/
     [18] http://www.w3.org/2001/tag/2002/webarch-20030206#uri-use
     [19] http://lists.w3.org/Archives/Public/www-tag/2003Mar/0018.html
     [20] http://esw.w3.org/topic/SelfDescribingWeb
     [21] http://esw.w3.org/topic/SelfDescribingWeb
     [22] http://esw.w3.org/topic/BeesAndAnts

          So i don't have to chase it up again:
          CP10. Agents which receive a resource representation
          accompanied by an
          Internet Media Type MUST interpret the representation according
          to the
          semantics of that Media Type and other header information.
          which generate representations MUST not generate Media Types
          and other
          header information (for example charsets) unless there is
          certainty that
          the headers are correct.

          so its basically, *disagree* with the media type registration

    Discussion of how to move forward on Architecture Document

          TB: Usual progress not happening here (incorporation of draft
          text after issue resolution). Although lots of people are
          queued up to write pieces, that's not happening. IJ could write
          an end-to-end draft and we could work from that.
          DC: That one doesn't appeal to me. I'd be happy to say TBL

          DO: But one reason we are gathered around this table is lack of
          TBL time.

          DC: I observe that TBL does the writing and that people don't
          react to it.
          CL: I agree with TB on how docs progress: someone just writes
          stuff.: Someone puts a stake in the ground and then you have
          something to push against.
          DC: That happens when the editor is really the author.
          TBL: The way the Process Doc works is that IJ puts it in his
          head. Not the same with the arch doc (for IJ). What are the
          reasons for the TAG document?
          IJ: Time is no longer the primary issue.: Primary issue is that
          I am not getting the sense of agreement that would allow me to
          run with small pieces and create text. One way to advance -
          small groups of editors to come up with more concrete TOCs for
          various sections.
          CL: I think real text is important; people need something to
          complain about.
          DC: To me the bottleneck is not writing up the decisions; it's
          making them.

          would quite like the paired-off 'buddy' system

          Section 5 should be just "Interaction" -- including UI to
          server actions

          DanC, you wanted to suggest that the arch doc actually does
          reflect the consensus of the group; there just isn't that much
          of it

          IJ: I disagree slightly on section on protocols; we've not had
          many discussions. Hard to say we don't agree.
          TB: On issues where we can hammer out consensus, writing them
          down will produce a meaty and useful arch doc. I think there
          are problems, but we have enough areas of consensus to publish
          something. E.g., look at our findings. On "[23]5.
          Machine-to-machine interaction" I think we have consensus on
          device-independence, lessons of REST, but that material not
          really there yet.
          TBL: Where is Web Services supposed to be?
          IJ: I think section 5.
          TBL: There's a fundamental difference between Web Services like
          things and ordinary Web things.

     [23] http://www.w3.org/TR/2003/WD-webarch-20030326/#interaction

          hm... perhaps, TBray; but it's not clear to me where Ian should
          go to get the material

          DO: I got the impression that TBL thought about Web Services
          interactions as different from Web interactions...
          TBL: Some Web Service interactions are very Web-like. But the
          architecture of Web Services is fundamentally messages that are
          part of larger protocols. They are not part of transferring the
          state of global information space. Some Web Services are
          retrieval operations, and some are not.
          DO: Roy asked a question a few months ago - are we writing the
          arch of the current or future Web.
          DO: I thought the answer at the time was more about "what has
          been". I'd love it if we worked on a more encompassing arch
          doc, but I wasn't aware that that was our mandate.
          TBL: I agree that the arch doc should encompass what we are
          doing within W3C.
          TB: The list under 4.5 has lots of useful consensus material
          that needs writing up.
          RF: It would be easier for me if we talked about the future Web
          within this arch doc. It's easier for me to lay out the
          sections in my mind. E.g., I consider everything that TBL
          described to be under "Interactions"
          SW: How do we relate to WSA WG?
          CL to TBL: How is what you are saying about Web Services
          different from Semantic Web interactions
          TBL: Whether you send in a msg or a Web service, the Sem Web is
          for talking about real things in a logical way. You can send
          messages or create documents. The distinctions are orthogonal.

          not finished yet btw

          CL: So, e.g., the Sem Web is that "this nut is compatible with
          this bolt if they have the same thread size; as defined over
          here at this URI"

          Chris how is SW different from WS?

          CL: Whereas Web Services is "I want to buy 10k nuts if they fit
          on this bolt over here."
          TBL: When you say "I want to buy them", that's part of the Web
          Services architecture.
          CL: But that's the real world -- it costs you money. I'm not
          seeing a real difference here; this is still about
          machine-to-machine communication.

          so, sw and ws seem like very closely related things, in summary

          DO: I would like to talk about diff between Sem Web and Web
          Services in the arch doc. My personal opinion is that the focus
          of Web Services is "how do you send messages back and forth;
          and how do you describe the messages in the exchange." I see
          the Sem Web as how you make assertions about things and then
          make queries (in a reduced world) with constraints. Yes you can
          put queries in messages...these two worlds intersect.

          TBray, you wanted to note that the only real industrial SW tech
          applications I've seen have been in WS apps

          TB: To me it's obvious that the overlap is very substantial.
          I've seen people doing Web Services deployment realize that
          they need vocabularies. I think that they are inextricably in
          bed with one another.
          TBL: I think that you find that when you use one you often use
          the other. But conceptually, they are very different parts of
          the architecture. You often use TCP and HTTP together. But they
          provide different services . Sem Web moves information space
          from bits to statements about real-world things. Combining Web
          Services and Sem Web is powerful. But there will be apps that
          use one without the other. We are not writing an article for
          Business Week; we are writing up architecture principles. So,
          e.g., model real-world things in your app, not documents.

          timbl, you wanted to say that the overlap in application area
          is very large, but the overlap in concept (which befits the
          arch doc) is smaller

          TBL: I can demonstrate cases where you use one without the

          I don't think Web Services can really get to first base without
          shared semantics a la SW. And all the SW golden-future stories
          I read have observable effects that sound a lot like WS.

          DO: I agree we are writing an arch doc. The WSA WG is also
          writing an architecture document. In the [24]14 Nov 2002 draft
          of the WSA Arch Doc ([25]3 Basic and Extended Architecture), I
          proposed some text about Web Services using language of Roy's

     [24] http://www.w3.org/TR/2002/WD-ws-arch-20021114/
     [25] http://www.w3.org/TR/ws-arch/#basicext

          Inextricably intermingled? test cases: Library ctalog = sem web
          without WS; document validation sWS = WS without SW maybe?
          Ordering machine parts could be a SWS case.

          DO: Maybe we can document differences and similarities.

          I think the library folks would disagree with the "without WS",
          timbl. They're webizing Z39.50 using SOAP all over the place.

          DO: We need to decide whether we're documenting one
          architecture or N.
          DC: It is?
          DO: I think the understanding we've had so far is that we are
          writing the Web architecture w.r.t. REST, excluding things like
          Web Services and Semantic Web.

          (I consider our issues list as the authoritative list of
          decisions we owe)

          WS without WS - foaf?

          (and perhaps a decision that says 'this document is consistent
          with our decisions on all these issues')

          TB: I think the arch doc will exhibit progress when one or more
          people take ownership of one or more sections and write them. I
          don't think we can divorce content from TOC. I am convinced we
          have consensus around enough points that we can produce a
          useful document. I'm not arguing that the current TOC is wrong;
          I'm arguing that we need text from start to finish, and we need
          to roll up sleeves and write it.

  2.2 IRIEverywhere-27 and URIEquivalence-15

     * [26]IRIEverywhere-27
          + Action CL/IJ 2003/03/17: Send edited piece that CL/MD/IJ
            wrote to www-tag. CL expects this by 31 Mar.
          + Text for other specs?
          + See [27]email from Larry Masinter
     * [28]URIEquivalence-15
          + Completed action SW, PC 2003/03/24: Review [29]IETF draft on
            URIs to see whether text satisfies URIEquivalence-15.

     [26] http://www.w3.org/2001/tag/open-summary.html#IRIEverywhere-27
     [27] http://lists.w3.org/Archives/Public/www-tag/2003Mar/0063.html
     [28] http://www.w3.org/2001/tag/open-summary.html#URIEquivalence-15
     [29] http://www.apache.org/~fielding/uri/rev-2002/rfc2396bis.html
     [30] http://lists.w3.org/Archives/Public/www-tag/2003Mar/0070.html

          CL: Text of this [31]IJ/MD/CL discussion needs to change
          ($Date: 2003/04/01 16:32:57 $)

     [31] http://www.w3.org/2003/01/22-iri27.html

          to me, what chris just said is the heart of the issue.

          CL: No longer true: " 1. RFC2396 should be modified so that hex
          digits (HEXDIG) are case-insensitive. "
          DC: Please include the Kanji example in this document.
          CL: TB's how to compare distinguishes case where you
          dereference and where you do not. I am proposing that the cases
          where you don't dereference are treated by simple Unicode
          string matching. However the next level up works on all schemas
          and you are dereferencing; upper lower case hex should be same;
          same with Kanji example; I think that this should be
          RF: Why do IRIs affect RFC2396 bis?
          CL: Would be weird if Kanji lowercase hex isn't the same as
          Kanji uppercase hex. Does not depend on URI scheme.
          RF: Need to convert from IRIs to URIs for comparison, though.
          CL: Aha! No need to do this comparison any more if you are not
          dereferencing the IRIs.

          (RF said they compared the same because you convert to URI
          before comparison)

          RF: If you are going to use an IRI as a namespace id, you're
          going to want to convert to URI first, otherwise, you'll have
          differences in the use of that identifier. You create a lot of
          unnecessary duplicates if you don't convert first.
          CL: Encoding has nothing to do with this. These are Unicode
          character codes. Assume it's in IRI form. Why would you convert
          to URI?

          "most common is URIs"... not in XML implementations

          RF: Most common use of identifiers is as URIs; you'll have IRIs
          sometimes and URIs sometimes. If you don't convert to URIs
          first, you won't have uniformity.
          CL: When you are not dereferencing, case matters. The available
          evidence from people who do namespace stuff is that they do
          string comparison. It's pushing too much water uphill for
          namespace case.
          RF: So you are relying on "If you want uniformity, use things
          CL: I can't get my preferred position, so my new position is
          closer to what the world will accept.
          RF: There are situations where IRIs are not as useful due to
          lack of deployment.

          w+ to say that we were asked to fix a problem; if we documented
          the current situation, we would document a mess. We could
          suggest an alternative. Eg. We could recommend that string
          comparison be limited to URIs only, and people not use IRIs
          until then can do IRI-URI mapping.

          SW: Larry, I think, is advising us to be patient and wait until
          there's an RFC.


     [32] http://www.w3.org/International/iri-edit/draft-duerst-iri.html

          DanC, you wanted to say why it maybe should depend on the
          scheme and to observe that the genie is out of the bottle here

          DC: There's text in XML namespace spec that says you can't have
          two attribs with the same name after they are namespace

          good test case there

          DC: You can tell (for Kanji case) whether your namespace
          implementation was happy. When I coded this up, I converted IRI
          to URI before comparison. It worked; that's a coherent position
          .I looked up in the world and I saw that there's an enormous
          tide of people doing it the other way: All XPath, XML Query,
          XML Schema implementations.

          I agree its a coherent position. i t was my first choice. But
          its not the majority position

          DC: HTML implementations use heuristics to maximize @@missed@@

          everyone does unicode character by character comparison

          DC: The way you get shared understanding of a name is to repeat
          verbatim in lots of contexts. The more mangling we have, the
          higher the risk of confusion.

          mixing up the hexified and non-hexified forms is a problem
          they do no collide
          the kanji form is te correct canonical form, written correctly

          DC: I think that the right answer is: (1) In the specific case
          of namespace names - no they do not collide unless they match
          unicode-char by unicode-char (2) this is rationalized in the
          real world since a person wanted to write their name the way
          that person usually does.

          timbl, you wanted to agree with Roy and re explain it if chris
          hasn't got it and to say that while the URI spec licences the
          conversion between 8bit and hexified froms, then they
          ... will be equivalent. and to say that we were asked to fix a
          problem; if we documented the current situation, we would
          document a mess. We could suggest an alternative. Eg. We
          ... could recommend that string comparison be limited to URIs
          only, and people not use IRIs until then can do IRI-URI

          TBL: If we documented the current situation, we would document
          a mess.

          possible solutions -- insist on hexifying for comparison, or
          forbid hexifying by clients. (iri proposal suggest the former;
          danc proposal leads to the latter)

          we *could* insisst on hexifying always but this would not work

          TBL: String comparison is fine BUT, you're not allowed to use
          IRIs until you've got your IRI-to-URI conversion working.

          + Plan A: URIs rule and that IRIs are one way of talking about
            URIs. I would argue that this is not pushing too much water
          + Plan B: Hexifying does not work. %xx are just characters.
            Client can't change. When you send across medium, these are
            Unicode strings - each protocol has to say how to handle

          hexifying isa last-ditch, late conversion to get an IRI through
          a non 8 bit clean protocol
          which is basically what I understand to be the IRI position

          TBL: Plan B says that namespace can do char-by-char Unicode and
          everyone else has to deal with it.
          RF: Does this mean IRI comparison should convert URI to IRI
          CL: No. All URIs are already IRIs.
          DC: There is a plan C in RF's question - the two spaces are
          isomorphic. You peek inside hex encoding.
          CL: It's better to say - once you've done hexing you've got a
          different thing. It's still an IRI, but doesn't use other chars
          than ASCII

          yes, plan C conflicts with the "if you mean the same thing, say
          it the same way" principle

          RF: An IRI that uses chars outside ASCII char set will be less
          "interoperable" than one that contains only ASCII chars.

          The isomophism creates some equivalences which break plan C

          DC: This is like a health warning: don't use "l" and "1" to
          avoid confusion.
          RF: Problems include email, RFCs munging text, ... I anticipate
          times when IRI will be used as namespace and people will want
          to use it in its URI state.
          CL: For the data entry problem, you can already type things in
          in ASCII. That aspect is already dealt with for XML.

          TBray, you wanted to agree with TimBL

          TB: I think that DC's experience with pushing water uphill is
          correct. If you are staying in the URI universe, then the
          approach taken so far (strcmp) is important - people should use
          the same name for the same thing. In a URI world, that's ok.
          (and bots can be more aggressive) For IRIs, I think we have to
          push some water uphill.

          because bots do dereferencing type things
          timbray asks if 'all uris are iris' are cast in stone
          believe so, yes

          TB on the whether a URI is already an IRI: I think that the
          rules about hexification non-deterministic.

          hexification always when needed, never when not needed

          TB: If we could require that hexification always when needed
          and never when not needed, then we'd have more leverage to
          attack the IRI problem.

          timbl, you wanted to propose that there is lots more water to
          be pushed uphill in plan A

          TBL: There is lots more water to be pushed uphill in plan A. I
          don't see Plan C working.

          2.3 IRI Equivalence and Normalization

          I propose we say a URI is *not* an IRI if it's got unnecessary

          "It follows from the above that IRIs SHOULD NOT be modified
          when being transported. "
          "In some scenarios a definite answer to the question of IRI
          equivalence is needed that is independent of the scheme used
          and always can be calculated quickly and without accessing a
          network. An example of such a case might be XML Namespaces
          ([XMLNamespace]). "

          TBL: I feel that when you compare pushing water uphill to
          number of places where URIs are communicated over 7
          bits....that world is much more diverse. That is MUCH MORE
          water to push uphill. You'd have to divide the Web in two.

          disagree that it slits the web in two
          *not* doing IRI would certainly split the Web into n parts,

          TBL: If we try to move to the world where URIs are replaced by
          IRIs, I think it's easier to get namespace-aware software to
          change (convert then compare). That's a more numerable set of

          DanC, you wanted to discuss world-wide charset and to agree
          that the rules around hexifying are frightening; cf XML query
          spec and to observe that we are in web phase 2

          DC: Regarding interoperability of IRIs/URIs, my experience is
          that if you want to use a URI that will really work everywhere,
          you should use [2-9] and that's it. I agree that the hex rules
          are frightening; the XML Query folks ran across problems
          recently. To me, hexifying is something the URI owner gets to
          do and nobody else gets to look into.

          'no peeking inside' - IRI spec agreres about that
          3.2 Converting URIs to IRIs
          In some situations, it may be desirable to try to convert a URI
          into an equivalent IRI. This section gives a procedure to do
          such a conversion. The conversion described in this section
          will always result in an IRI which maps back to the URI that
          was used as an input for the conversion (except for potential
          case differences in escape sequences). However, the IRI
          resulting from this conversion may not be exactly the same as
          the original IRI (if there ever was one).

          DC: As to TBL's comment on water in 7-bit URI world: Maybe. But
          water not all flowing in the same direction. I remain convinced
          that using strings of Unicode chars for resource names is the
          correct option.

          yes, or no, paulc: do we discuss issue 8 today?

          would prefer to try and get this issue with some agreement so i
          can edit this document

          [TAG agrees to address issue 8 next week]

          I think we have agreement that

         1. IRIs are a good thing, and
         2. URIs are not going away so the URI->IRI conversion is a
         3. we need real clarity on URI<->IRI interconversion rules &
            when to do

          yes, clearly on 1)

          NW: I agree with RF's comment - I think it will remain the case
          for some time that URIs work where IRIs don't.

          for months now

          Norm, you wanted to say that there is simply existing software
          that insists on ASCIII

          yeah, well, solving world hunger is a good thing. but I'm not
          going to 2nd a proposal to solve it, setting expectations that
          we're not going to meet.

          TBL: I suggest that CL write down Plans A and B.

          document both options and discuss them

          roy, you're wrong. IRI does exist. It's the norm in practice.

          CL: Yes, I agree that it's a good idea to write down both
          RF: If the issue is that IRIs should be everywhere, then we
          need to be clear on what IRIs are. IRI docs are still
          undergoing big changes. I am happy to reconsider this issue
          when IRI and URI specs stabilize.

          Roy, you wanted to say that I agree with Larry's comment: the
          only finding is that IRI does not yet exist

          the implementations have consensus and have done for a long

          DC: I observe more consensus in the implementations than in the
          spec. The fact that the users are happy to invest in this
          technology early suggests to me that we owe the community a
          spec for what they're doing.

          because the rest of the world wants to use its own characters

          DC: I'm talking about XML* specs, not just IRI specs.

          Solution: the attribute is CDATA, not an IRI or URI

          TAG should request that draft-duerst04 moves to an RFC asap

          DC: The status quo is that people cut/paste IRI text directly
          into their specs.

          timbl, you wanted to say we need to define equivalence more
          widely than one WG

          TBL: We've been asked to say when URIs/IRIs are equivalent. I
          think it would be a shame to leave it as "Pick your favorite of
          7 levels"

          it has been pointed out before that equivalence does indeed
          depend - it depends on the equivalence operator that you are
          and there are only two levels, in fact

          TBL: Plan A says IRI_1 and IRI_2 equiv when same string of
          Unicode chars. Plan B says IRI_1 and IRI_2 are equiv when
          hexified and string compared.

          well, not strcmp but wide-strcmp

          DC: The only guy who gets to hexify is the guy who makes up the
          URI in the first place.
          [Discussion of Internet Explorer behavior - been doing Plan B]

          (except that I didn't really mean that. yes, I did say that.)

          doing plan b when they dereference
          doing plan a when they compare without dereference

          RF: Like LM, I think we need to wait for the next IRI draft.

          roy says that international domain names now ratified so martin
          will update the spec to reflect this

          sorry bye

          DC: So Martin writes some text. But we need to get agreement
          with lots of people (including W3C groups and outside W3C). So
          TAG should actively coordinate among these groups. E.g.,
          provide tests.
          SW: Another thing in LM's message - creation of an IRI mailing
          list. Is the IETF the venue for this meeting?
          DC: An IETF WG could be.
          RF: Discussion of draft is taking place on a W3C mailing list
          for the purpose of advancing spec within the IETF.


     [33] http://www.w3.org/International/iri-edit/

          The mailing list for public discussion of IRIs is
          public-iri@w3.org, with a public archive. To subscribe, send
          mail to public-iri-request@w3.org with subscribe as the

          RF: It would be ideal to endorse this as the home and get
          people to talk there.
          [Some discussion that CL and DC would be uncomfortable with
          providing text to groups with a guarantee that it would pass
          muster at doc transition.]
          Action CL: Revise the IRI position draft for next week.

  2.3 Issues that have associated action items

     * [34]namespaceDocument-8
          + Next steps on [35]RDDL Proposal from Tim Bray/Paul Cotton
     * [36]xmlIDSemantics-32
          + Status of Chris Lilley draft finding in this area? See
            [37]early snapshot from CL
     * [38]abstractComponentRefs-37
          + Completed action TB 2003/03/24: Summarize TB's opinion on
            this discussion and relation to other issues. ([39]Done)
     * [40]xlinkScope-23
          + Status report?
          + See [41]draft, and [42]SW message to CG chairs.
     * [43]siteData-36
          + Action TBL 2003/02/24 : Summarize siteData-36
     * [44]xmlFunctions-34
          + Action TBL 2003/02/06: State the issue with a reference to
            XML Core work. See [45]email from TimBL capturing some of the
     * [46]binaryXML-30
          + Action TB 2003/02/17: Write to www-tag with his thoughts on
            adding to survey.
          + Next steps to finding? See [47]summary from Chris.
     * [48]contentPresentation-26
          + Action CL 2003/02/06: Create a draft finding in this space.
            Deadline 3 March.
     * [49]rdfmsQnameUriMapping-6
          + Action DC 2003/02/06: Propose TAG response to XML Schema
            desideratum ([50]RQ-23).
     * [51]uriMediaType-9
          + Action DC 2003/02/06: Start discussion on
            discuss@apps.ietf.org, but not urgent
     * [52]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 [53]message from Larry Masinter w.r.t. Web services.
     * [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. Deadline first week of March.
     * [55]metadataInURI-31
          + Action SW 2003/02/06: Draft finding for this one.
     * [56]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.

     [34] http://www.w3.org/2001/tag/open-summary.html#namespaceDocument-8
     [35] http://lists.w3.org/Archives/Public/www-tag/2003Feb/0213
     [36] http://www.w3.org/2001/tag/ilist#xmlIDSemantics-32
     [37] http://lists.w3.org/Archives/Member/tag/2003Mar/0102.html
     [38] http://www.w3.org/2003/03/24-tag-summary.html#abstractComponentRefs-37
     [39] http://lists.w3.org/Archives/Public/www-tag/2003Mar/0064.html
     [40] http://www.w3.org/2001/tag/ilist.html#xlinkScope-23
     [41] http://lists.w3.org/Archives/Member/tag/2003Mar/0094.html
     [42] http://lists.w3.org/Archives/Member/tag/2003Mar/0104
     [43] http://www.w3.org/2001/tag/ilist.html#siteData-36
     [44] http://www.w3.org/2001/tag/ilist#xmlFunctions-34
     [45] http://lists.w3.org/Archives/Public/www-tag/2003Feb/0309.html
     [46] http://www.w3.org/2001/tag/open-summary.html#binaryXML-30
     [47] http://lists.w3.org/Archives/Public/www-tag/2003Feb/0224.html
     [48] http://www.w3.org/2001/tag/open-summary.html#contentPresentation-26
     [49] http://www.w3.org/2001/tag/open-summary.html#rdfmsQnameUriMapping-6
     [50] http://www.w3.org/TR/2003/WD-xmlschema-11-req-20030121/#N400183
     [51] http://www.w3.org/2001/tag/open-summary.html#uriMediaType-9
     [52] http://www.w3.org/2001/tag/open-summary.html#HTTPSubstrate-16
     [53] http://lists.w3.org/Archives/Public/www-tag/2003Feb/0208.html
     [54] http://www.w3.org/2001/tag/open-summary.html#errorHandling-20
     [55] http://www.w3.org/2001/tag/open-summary.html#metadataInURI-31
     [56] 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/04/01 16:32:57 $

Ian Jacobs (ij@w3.org)   http://www.w3.org/People/Jacobs
Tel:                     +1 718 260-9447
Received on Tuesday, 1 April 2003 11:37:45 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:55:58 UTC