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

[Minutes] 9 Jun 2003 TAG teleconf (Arch Doc walkthrough, W3C/IETF mtg)

From: Ian B. Jacobs <ij@w3.org>
Date: 10 Jun 2003 11:28:48 -0400
To: www-tag@w3.org
Message-Id: <1055258928.900.256.camel@seabright>


The minutes of the TAG's 9 Jun 2003 (2.5 hour) teleconf
are available as HTML [1] and as text below.

 - Ian

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


                   Minutes of 9 June 2003 TAG teleconference

1. Administrative

    1. Roll. All present: SW (Chair), TBL, DC, TB, DO, RF, CL, PC, NW, IJ
    2. Accepted minutes of [8]12 May teleconf and [9]2 Jun teleconference
    3. Accepted this [10]agenda, with addition of item on W3C/IETF
    4. Next meeting: 16 June. Regrets: PC

      [8] http://www.w3.org/2003/05/12-tag-summary.html
      [9] http://www.w3.org/2003/06/02-tag-summary.html
     [10] http://www.w3.org/2003/06/09-tag.html

  1.2 W3C/IETF meeting


          DC: IETF/W3C teleconf is 17 June. Might talk about mime types.
          Do you want anything on that agenda?
          TB: We wanted them to provide web space and canonical URIs for
          mime types.

          where's that IANA/IETF mime-type directory?

          DC: Maintaining "tidy uris" - promise to keep http URIs to mime
          types and to give 1 year notice if they will change. Another
          issue is I18N URIs.

          Chris, you wanted to ask abou IDNA and process stuff and to
          also ask about URI mime registry and correct forum

          CL: Is talking to Ned Freed the correct forum for pushing for
          tidy URIs?
          [CL has an action item]
          DC: Norm in IETF is to address author. In general, ok to cc
          public w3c/ietf mailing list
          CL clarifying: Is our action the same?
          TB: As I recall, DC had sent us a place in IETF land where all
          the mime types were on one page. However, as I recall, it was
          only really halfway there.
          TB: I think CL had accurately described the pbs in his
          Message-ID: <10684031578.20030228173630@w3.org>
          To: webmaster@iana.org, CC: www-tag@w3.org,
          DC: Ned is editing the policy that says they have to do it
          right. Make it policy through Ned Freed.
          CL: I'll forward to w3c/ietf liaison list:

     [11] http://www.iana.org/assignments/media-types/image/cgm
     [12] http://lists.w3.org/Archives/Public/www-tag/2003Feb/0302.html

          if you mail me about IETF/W3C business, pls copy

          DC: Please read NF's policy document.
          CL: I have read that.
          DC: I pinged him to make a new draft; hoping he'll have one by
          17 June
          CL: What about i18n domain names?
          RF: I18N domain names are done: IDNA is done; see [13]RFC 3490
          (Internationalizing Domain Names in Applications (IDNA)) and
          3491. Both Standards Track.
          SW: What about talking about URLs/URNs at 17 June mtg?
          DC: No urgency for 17 June meeting

     [13] http://www.ietf.org/rfc/rfc3490.txt

          URL = Universal Republic of Love

          URN=not liked, URC=not implemented, thus URI== URL

          neat trick since URL and URC don't exist...

          oh, *minor* issue of detail ;-)

          hmm... the xml.gov interaction didn't bubble up into an issue?

          DC: I can tell the IETF that we have some activity going on
          around this topic (though no formal issue).

2. Technical

  2.1 Architecture document

   The TAG expects to pick up where it left off (approximately section
   3.2) and to complete its walk-through of the Arch Doc.
    1. [14]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.
            DC requests to withdraw this one.
         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 [15]message passing, a dual of
            shared state. DC refers us to [16]Conversations and State

     [14] http://www.w3.org/TR/2003/WD-webarch-20030326/
     [15] http://lists.w3.org/Archives/Public/www-tag/2003Mar/0018.html
     [16] http://www.w3.org/DesignIssues/Conversations

   Actions from 2 June meeting:
    1. RF to rewrite section 5. Section 5 is expected to be short.
    2. TB to rewrite section 4 based on his [17]proposal for rewriting
       section 4and suggestions from the TAG from 2 Jun teleconf.
    3. CL to make available a draft finding on content/presentation.
    4. DO to update [19]description of [20]issue abstractComponentRefs-37
    5. SW: to continue work on and make available a draft finding related
       to the opacity of URIs.
    6. NW: Take a stab at proposed new 4.5, wherever it ends up.
    7. DO: Write up a couple of paragraphs on extensibility for section
    8. IJ: to start incorporating detailed suggestions on Arch Doc made
       by the TAG (see [21]IRC log for details)

     [17] http://lists.w3.org/Archives/Public/www-tag/2003May/0101.html
     [18] http://www.tbray.org/tag/wa-c4.html
     [19] http://lists.w3.org/Archives/Public/www-tag/2003Apr/0089.html
     [20] http://www.w3.org/2003/06/24-tag-summary.html#abstractComponentRefs-37
     [21] http://www.w3.org/2003/06/02-tagmem-irc.html

          [Reviewing where we were in 3.1]
          At end of meeting last week we were talking about references to
          CL: I request that we ignore IRIEverywhere-27 for this
          teleconf. I expect to send in some clarifying material soon.
          RF: Move the IRI bit at the end of 3.1 (whatever it says) to a
          "Future directions" section for this leg of the tripod.
          [Some agreement]
          [3.2 URI Schemes]
          RF: I rewrote this in 2396bis. Looks like first three paras of
          arch doc (but more accurate than arch doc). Text in rfc2396bis
          is more specific about role of schemes.
          DC: I'm not thrilled about idea of cutting the text.
          RF: I suggest reusing RFC2396bis text and including reference.
          TB/PC: Why redundancy here valuable?

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


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

          DC: The URI draft says "mailto scheme for email addresses" but
          says that "news is for usenet groups/articles". Please
          harmonize types in the list of examples in RFC2396bis (e.g.,

          Each URI begins with a scheme name that refers to a
          specification for assigning identifiers within that scheme. As
          such, the URI syntax is a federated and extensible naming
          system wherein each scheme's specification may further restrict
          the syntax and semantics of identifiers using that scheme.

          RF: More specific - "URIs ARE classified by scheme"

          sounds like keyboard/mic too near desk issues

          Action IJ: compare 3.2 text with RFC2396 version 3; compare and
          harmonize; leaving about the same amount of text.
          TB: In section 3.2, important thing is "New URI schemes". SO
          make sure that: (1) reader understands what a scheme is (2)
          reader has correct reference to URI spec.
          RF: I think TBL and perhaps DC would like to emphasize the para
          I copied in - in the sense that one specification leads to

          er... "layering"?

          TB: Problematic to use myscheme: blort since there's no place
          to go look for it.

          yep, layered specifications

          [Discussion about new URI schemes]
          DC: They are extensible, locally (e.g., on my machine)
          DC: We don't have a cogent argument in our doc against creation
          of new uri schemes. E.g., if you are Apple, deploying new URI
          schemes is easy (since Apple controls desktop).

          would writing an rfc saying 'this is http spelled different'
          make it non-proprietary

          yes, bray's got it right here... 'if it has an existing name,
          use that name' derivable from network-effects principle

          TB: I think the apple thing is a test case. The reason it's the
          wrong thing do to is that the information is available by HTTP
          (music store responds to http requests). Despite that fact they
          identified with a new URI scheme. It's bad since I could have
          shared HTTP uri with more people.

          okay. what if its a defined http subset, like a get-only

          DC: "If it has an existing name, use it." This derives from the
          network effect principle.

          We should focus on the need to register new schemes and the
          built-in reluctance in the IETF to allow registrations of
          schemes that do not add value over existing set.

          DanC, you wanted to comment on examples and to and to riff on
          multi-party motivation

          DC: Apple should have keyed off of mime type. But in the
          calendar case, they wanted people to put ics files on the Web.
          Think globally.
          CL: Perhaps one reason they did this was to subset HTTP. That
          would be an advantage to a new scheme.

          Answer: no, they wanted webdav URI as well.

          PC: What special processing do these scheme resources get?

          webcal: is of course similar

          TB: I'm pretty convinced that there's no difference. Most of
          the xml downloaded (before encryption) had to do with

          wierd! why is "only two tags, key and value" stupid, but RPV is
          better than RDF/XML syntax?!?!?!


          TB: They should have published standard HTTP URIs for these
          resources and registered a mime type for the weird xml.
          PC: So we are saying - don't create URI scheme; register your
          mime type.
          RF: The registration process for URI schemes is being revised.
          In any case, we should emphasize in this section that the URI
          schemes have to be registered. Part of the registration process
          for URI schemes is MORE STRICT than the one for mime types.

          strict registration process for schemes won't make them more
          likely to get registered. :-{

          Chris, you wanted to point out that new schemes fits with rhe
          upcoming component extensions work

          RF: IETF rejects proposed schemes if deemed that they serve no
          useful purpose.
          CL: Component extensions work at W3C.

          Rumor is that they did this because Safari's mime-type
          dispatching is horribly inflexible

          yes, webdav: was rejected for that reason

          tim_mit, you wanted to discuss why it is harder to do it with a
          new mime type, and therefore to suggest comments on the
          software architecture which follows.

          which scenario are you speaking to, timbl? webcal: or items:?

          DAV: was not rejected

          TBL: It comes down to your software architecture. A typical
          dispatcher either (1) munges internally or (2) downloads and
          figures out what software to run on it. Apple registry may
          split "application" v. "extension" (like old days)

          aha! of course! we need http-head://www.w3.org/ vs.
          [24]http://www.w3.org/ , right, Ian? ;-)

     [24] http://www.w3.org/

          TBL: One problem is two links that refer to the same thing
          (e.g., webcal v. http URIs which mean different things
          (different verbs for different uri schemes))

          How does this discussion result in text for webarch?

          the subscribe vs. copy choice is much like the "new window" vs
          "new tab" vs same-window choice.

          it relates to 'don't make new schemes unless you need to'

          TB summarizing:

         1. Gratuitous invention of URI schemes is not a good idea.
         2. State what the decision criteria are that would strengthen or
            weaken the attractiveness of a new URI scheme.

          it still sounds like different schems, like get vs something
          else, to me
          subscribe is clearly having a side effect and should not use
          get method

          2) Gratuitous invention of RDF is not a good idea. On these two
          laws hang all the law and the prophets. ;-)

          TB: The interaction in apple case is HTTP; no functions
          required that can't be done in HTTP; and wider applicability a
          good thing => use HTTP uri scheme. If you want a URI and if
          scheme exists that meets your needs and
          there is a requirement for usage across wide range of
          users/applications, then don't invent new one.
          SW: Any value in enumerating what the costs are?
          TB: Even if URI being invented for private reasons, usually one
          finds public reasons.
          IJ: Point to deep linking finding as well (basically "Keep your
          options open."). Sell it as a benefit - this keeps your options

          tim_mit, you wanted to suggest text for document along the
          lines that "Client-side flexibility in the dispatching of new
          MIME types should be suficiently powerful to allow new
          ... MIME types to introduce the necessary functionality"

          [TBL: They could have introduced itunes as a sherlock plug-in]
          TBL say:

         1. Dispatching on mime types is a useful thing
         2. We should write up the webcal story or the itunes story in a

          Explain why you lose when you do it that way (itunes or webcal)

          hear hear. stories to supplement principles


         1. Identify different ways of achieving extensibility
         2. Relative costs

          TBL: Can we have a finding on this? Can TB provide this text as
          a finding?
          TB: Sure, go ahead.
          DC: Tell a story in the finding and seek a balance between
          finding an arch doc.

          but no more XML (sob):

     [25] http://www.tbray.org/ongoing/When/200x/2003/05/14/AppleShutdown

          Action IJ: Turn [26]TB apple story into a finding.
          RF: On editor's note at end of 3.2? I think we should talk
          about this, and that it should be in another section.
          [this = authority component]
          RF: Somewhere we should talk about how URIs are allocated. Some
          are allocated using their own mechanisms; most are via
          authority delegation. See 3.2 of RFC2396bis for info about
          authority info. URI spec doesn't really talk about the social
          aspects of delegating name allocation. We should probably
          create a new toplevel section (3.x) on name allocation.
          IJ: I'd like to make connection between meaning of resource and
          authority over that meaning.

     [26] http://www.tbray.org/ongoing/When/200x/2003/04/30/AppleWA

          RF: "Allocating URIs"
          Action IJ: add a new 3.x section on allocating URIs; taking
          some text from rfc2396bis/3.2 and expanding slightly on social

          [3.3. Fragment identifiers]
          TB: There's lots of new stuff in rfc2396bis. See [27]section
          3.5 Notion of a "Secondary Resource" : "The fragment identifier
          component allows indirect identification of a secondary
          resource by reference to a primary resource and additional
          identifying information that is selective within that
          TBL: I don't like the piece in the arch doc about "part or
          Action IJ: Integrate RF's 3.5 into from RFC2396bis into arch
          doc section 3.3.
          TB: For RF's 3.5, there are some issues related to RDF. I'll
          send some text; I think people will disagree with "frag id
          identifies something selective within a resource"
          IJ: Recall that I will be trying to keep one story throughout
          arch doc; I will probably do some combination of RF text +
          adding to the first scenario in the arch doc.

     [27] http://www.apache.org/~fielding/uri/rev-2002/draft-fielding-uri-rfc2396bis-03.html#fragment

          before leaving RFC2396bis, shall we acknowledge RoyF's 2 week
          'last call' ish new-issue deadline, please, Norm/Stuart?

          Yes, DanC

          TBL (about RFC2396bis) : The secondary resource (identified by
          a thing with a #) is, like the primary resource, is determined
          by the naming authority. There should be consistency between
          primary and secondary resources. Just because you may not have
          a representation yet; the resource still exists.
          RF to TBL: Please read 3.5 soon to let me know if you're happy.
          RF about RFC2396bis: If draft hasn't changed in 2 weeks, then
          submitted to IESG for last call (for an internet-wide last
          call). I don't expect technical changes at this point. If there
          are minor wording changes, I'll produce a version 04 and then
          there will be an immediate draft to IESG. PLEASE make comments
          soon (within 2 week, ending 23 June).

          RFs request was ackowledged by the chair.

          TBL: There should be consistency between the idenity of primary
          and secondary according to the authority and any infromation
          returned in response to the dereferencing of the primary URI.

          [3.4. Dereferencing a URI]
          DC: Status of [28]metadataInURI-31?
          SW: I did a first draft of finding; haven't worked on it
          lately. There are various observers of URIs (e.g., origin
          server) and various parts of URIs that may be more or less
          opaque depending on the observer.
          DC: Is your expectation of having finding done by end of June?
          SW: I'd like to have finding in shape for our July mtg. I have
          comments to integrate before sending to www-tag.
          IJ: Big things won't happen for arch doc before end of June. I
          can have a good draft for ftf meeting.

     [28] http://www.w3.org/2001/tag/ilist.html#metadataInURI-31

          yeah... it's a real bummer for us to have these marathon
          meetings only to have the editor say "hold that thought for 2

          NW: Push story in 3.4.1 to earlier in 3.4. Move up "All
          important resources SHOULD be idnetified by a URI" since not
          about representations.
          TB: Yes, move to the top.
          IJ: Ok, I'll move that note higher up in the doc.
          TB: Put it in 3. (before 3.1). Under 3.4.2, put in the example
          of the bank account. When you say "Yes, charge my credit card
          for the ticket to Oaxaca" to expand on scenario in section 1.
          IJ: I can steal some text from finding to flesh out 3.4.2 a
          bit; it's barren as it stands.
          TB: Leave 3.4.3 with reference to deep linking finding.
          NW: Move 3.4.3 up (talk about identification without access
          before talking about access)
          [3.4.4 Servicing a URI]
          TB: Please include the word "persistence" in the title of 3.4.4
          NW: Yes. I'd like a different title for 3.4.4

          "predictability"? "consistency"?

          Some suggested alternative titles for section 3.4.4:

         1. Resource persistence and representation consistency
         2. Consistency

          NW: I think should be moved to 3.5 instead of 3.4.x
          TB: Another case is use of namespace name for different things
          over time. Leave moby dick example unless you can cover all the
          bases with expanded scenario.
          [Some agreement to move 3.4.4 to 3.5]
          RF: Add 3.6 - future directions.

         1. IRIs
         2. Things that are not administrative hierarchies (e.g.,
            freenet, [29]edonkey2000)
         3. Dereferenceable URNs; see DDDS work.

     [29] http://www.edonkey2000.com/

          [$1\47] Mealling, M., "Dynamic Delegation Discovery System
          (DDDS) Part
          One: The Comprehensive DDDS", RFC 3401, October 2002.

     [30] http://www.ietf.org/internet-drafts/draft-connolly-w3c-accessible-registries-00.txt

          TB: Anything in 3.4.4 (or three generally) that at the current
          time clashes with either TBL or RF view of what a resource is?
          RF: This text mixes up resource metadata and representation of
          the resource. Odd to see consistency of representations mixed
          with consistency of metadata; perhaps create a subsection for
          each. Consistency of both is a good thing.
          TBL: Fine by me to say that 2 URIs can identify the same

          how do you know - only by dereferencing and comparing the


          TB: If people are basically ok with section 4, we are within
          spitting distance of a coherent publishable document. How do we
          get to last call?
          DO: Question of scope of arch doc: Whether to include more on
          sem web and web services or not.

          what TimBL said

          TBL: I think we should go ahead with last call if we are happy
          with what we have.

          I think there's an attainable WD target in the near term. maybe
          that's so obvious that it's boring.

          but still worth stating

          TBL: We have got a subset. I think that DO is right that our
          scope includes Web Services, etc., but I don't think we save
          time by not publishing a last call.
          TB: I think that we need to take this through last call to get
          people to read seriously and have a stake in the ground. I
          can't imagine that it would be good to leave it in WD status..

          Chris, you wanted to talk about loaded questions

          CL: I agree we should take it to first last call. Might take a
          subset of the doc to Rec and work on rest separately.
          DO: Why did we ask the AC what they want?
          CL: Communication (what questions we face, tradeoffs we are
          considering making, awareness of our work)
          DO: Some people brought up the issue of "last call". Have we
          closed all of our issues?
          PC: I agree with DO; I think that there are a fair number of AC
          reps who want the arch doc to talk about web services and
          semantic web. If we decide that we have to put that info in the
          future directions sections, then I expect we'll get a bunch of
          comments.We'd need to indicate limits of doc in status section.
          Process Doc is a leading example of how to handle an evolving
          document (publish so often and cut off issues list)

          I won't be party to any decision to go to "first last call". if
          "last call" is treated like crying wolf, it'll further lose

          PC: the Adv. Board batches the effort. I'd like to go forward
          with a first last call, but bring to the AC's attention that we
          haven't gotten as far as some AC reps might like.

          DanC, you wanted to noodle on last call before... what? before
          we ask the AC who said they're not interested in a document of
          this scope? and to say "I won't be party to any decision to go
          to "first last call". if "last call" is treated like crying
          wolf, it'll further lose value."

          DC: I think we have clearly conflicting advice. I'd like to
          declare victory at an early opportunity. If we go to last call,
          we should be ready to go to the next step. Not sure whether
          next step should be CR or PR. We might be promising to "hold
          still" on the backward-looking part of the document.

          first last call means we have no guarantee that we get to cr;
          clearly if all review is positive then we go to cr, but lots of
          review often means lots of feedback, often for the first time

          DC: I would have hoped the AC would say -publish early publish
          often; but that's not the advice we got.
          RF: The section of interactions will have (even in skeletal
          form), something on http, web services, and sem web. How those
          categories impact the notion of interaction. I am on hook to
          finish this section for next week.
          TBL: I don't see how sem web part of interaction...
          TB: Most of current arch doc result of 10 years experience.


          TB: Not getting around the fact that as soon as we move to sem
          web and web services, our experience will be very different.
          Will be qualitatively different from what we have.

          "quite" re semweb/web-svcs being newer

          TB: We should get to a point where we think we've gotten to a
          point where we are happy with what we've written about how the
          thing works today; we owe that to the community.

          where was tbray during the AC meeting? 1/2 ;-)

          TBL: The Process Doc doesn't address this situation -
          half-completed document clashes with dfn of last call. One
          possibility is to say, e.g., "last call on arch doc, part I.
          "We'll be working on parts I and II, but think last call on
          part I reasonable.

          Chris, you wanted to agree about the 'from experience' part but
          we don't have all that down yet

          CL: Line through old / new stuff not that clear. People have
          been doing some aspects of web services for a long time. There
          is stuff that's not in the arch doc where we have experience
          but we haven't had time to work on it.

          (btw... I'm hoping the I18N WG splits the charmod spec
          likewise; did we ask them to do that? have we gotten a reply?)

          PC: Some TB text might be good rationale to take back to AC;
          why we are taking to last call now.

          we did ask them and they did not reply
          actually I believe they said no unoffiially

          PC: There are folks in Web Services area who want TAG's help in
          that area; would like to get us involved in that area sooner
          rather than later.

          so we need to fget an official answer

          PC: We need to respond to AC's signal
          SW: We have a WSARCH WG; I am not conscious of any issues that
          have been fed to us from that WG.
          PC: We have had direct requests from other wgs in that activity
          (e.g., wsdl).
          IJ: Issue 37, not to mention SOAP/GET
          PC: If the TAG decides that it wants to go to LC, has a mandate
          to respond to the AC, set expectations about material we will
          cover and how.

          tim_mit, you wanted to say that there is a lot of arch work
          already done in sw area which could be pointed to.

          TBL: Owl/RDF Core groups have done a bunch of architectural
          DO: I observe that we've had a couple of issues with web
          services groups; if we reacted quickly to questions from these
          groups we'd get even more questions.

          [DO mentions target resource attribute]

          DO: People that are in these communities aren't looking for TAG
          help on current issues in this area; we haven't expressed too
          much interest of being in those areas.
          IJ to TBL: Send me data on arch info related to sem web if
          you'd like included in references section.
          [Returning to schedule issue]
          TB: I think that going to LC/CR/PR is good on a document. If we
          don't do that sometime, then we won't benefit. If we have
          consensus that we would lke to get to LC sooner rather than
          later, then we should tell the AC and see if they are ok with

          Straw poll - July last call on arch doc part I?

         1. Yes: TB, DC, NW, CL, IJ, TBL, SW, PC, DO
         2. Abstain: RF

          I will be travelling almost all of June 19-July 24

          DC: Anyone want to take an action to reset expections within
          the AC?

          I'll concur. I think we wasted time asking the AC.

          DO: If we really wanted to go to last call end of July, we
          should have told the AC that. We should have set clearer
          expectations at the AC meeting; explained to them the down
          sides. I think the question we asked them missed the mark; we
          didn't get back information that we found useful.
          TB: That may be true, but until we went through the call today,
          I don't think we knew.

          yes, I think that's life... hindsight is 20-20.

          SW: Folks, please make progress on your action items before our
          next teleconf.
          Action DO/PC: Send draft of AC announcement to tag@w3.org.

3. Not addressed

  3.1 Findings

   See also: [31]findings.

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

   Next steps for draft findings:
     * [32]Client handling of MIME headers; see [33]summary of comments.
     * [34]URIs, Addressability, and the use of HTTP GET and POST; see
       [35]summary of comments. See also [36]comments from Larry
     * [37]How should the problem of identifying ID semantics in XML
       languages be addressed in the absence of a DTD?

     [32] http://www.w3.org/2001/tag/doc/mime-respect.html
     [33] http://lists.w3.org/Archives/Public/www-tag/2003May/0099.html
     [34] http://www.w3.org/2001/tag/doc/whenToUseGet-20030509.html
     [35] http://lists.w3.org/Archives/Public/www-tag/2003May/0099.html
     [36] http://lists.w3.org/Archives/Public/www-tag/2003May/0104.html
     [37] http://www.w3.org/2001/tag/doc/xmlIDSemantics-32.html

  3.2 New issues?

  3.3 Issues that have associated action items

     * [38]rdfmsQnameUriMapping-6
          + Action DC 2003/02/06: Propose TAG response to XML Schema
            desideratum ([39]RQ-23).
     * [40]whenToUseGet-7
          + Next step for [41]revised draft finding?
     * [42]namespaceDocument-8
          + Action TB 2003/04/07: Prepare RDDL Note. Include in status
            section that there is TAG consensus that RDDL is a suitable
            format for representations of an XML namespace. Clean up
            messy section 4 of RDDL draft and investigate and publish a
            canonical mapping to RDF. See TB's [43]1 June version.
          + Action PC 2003/04/07: Prepare finding to answer this issue,
            pointing to the RDDL Note. See [44]comments from Paul
            regarding TB theses.
          + Refer to draft TAG [45]opinion from Tim Brayon the use of
            URNs for namespace names.
               o RF: Folks assume that because the specs say so, URNs
                 will be persisitent. But persistence is a function of
                 institutional commitment and frequency of use.
     * [46]uriMediaType-9
          + IANA appears to have responded to the spirit of this draft
            (see [47]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?]
     * [48]URIEquivalence-15
          + SW proposal: Track RFC2396bis where [49]Tim Bray text has
            been integrated. Comment within the IETF process. Move this
            issue to pending state.
     * [50]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 [51]message from Larry Masinter w.r.t. Web services.
     * [52]errorHandling-20
          + Action CL 2003/02/06: Write a draft finding on the topic of
            (1) early/late detection of errors (2) late/early binding (3)
            robustness (4) definition of errors (5) recovery once error
            has been signaled. Due first week of March.
     * [53]xlinkScope-23
          + Status report?
          + See [54]draft, and [55]SW message to CG chairs.
     * [56]contentTypeOverride-24
          + Next step on finding "[57]Client handling of MIME headers"
          + [58]Speech Recognition Grammar Specification Version 1.0,
            section [59]2.2.2 External Reference by URI
     * [60]contentPresentation-26
          + Action CL 2003/02/06: Create a draft finding in this space.
            Due 3 March.
     * [61]IRIEverywhere-27
          + Action CL 2003/04/07: Revised position statement on use of
            IRIs. CL says to expect this by 21 April.
          + Action TBL 2003/04/28: Explain how existing specifications
            that handle IRIs are inconsistent. [62]TBL draft not yet
            available on www-tag.
          + See TB's[63]proposed step forward on IRI 27.
     * [64]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.
     * [65]binaryXML-30
          + Action TB 2003/02/17: Write to www-tag with his thoughts on
            adding to survey.
          + Next steps to finding? See [66]summary from Chris.
     * [67]metadataInURI-31
          + Action SW 2003/02/06: Draft finding for this one. See [68]SW
          + See also [69]TB email on Apple Music Store and use of URI
            schemes instead of headers
     * [70]xmlIDSemantics-32
          + See [71]Chris Lilley draft finding.
            Action NW 2003/05/05: Point Core WG to CL finding once made
     * [72]xmlFunctions-34
          + Action TBL 2003/02/06: State the issue with a reference to
            XML Core work. See [73]email from TimBL capturing some of the
     * [74]siteData-36
          + Action TBL 2003/02/24 : Summarize siteData-36
     * [75]abstractComponentRefs-37
          + See [76]issue description from David Orchard. Next steps?

     [38] http://www.w3.org/2001/tag/open-summary.html#rdfmsQnameUriMapping-6
     [39] http://www.w3.org/TR/2003/WD-xmlschema-11-req-20030121/#N400183
     [40] http://www.w3.org/2001/tag/ilist.html#whenToUseGet-7
     [41] http://www.w3.org/2001/tag/doc/get7-20020610.html
     [42] http://www.w3.org/2001/tag/open-summary.html#namespaceDocument-8
     [43] http://www.tbray.org/tag/rddl/rddl3.html
     [44] http://lists.w3.org/Archives/Member/tag/2003Apr/0046.html
     [45] http://lists.w3.org/Archives/Public/www-tag/2003Jun/0003.html
     [46] http://www.w3.org/2001/tag/open-summary.html#uriMediaType-9
     [47] http://lists.w3.org/Archives/Public/www-tag/2003Feb/0302.html
     [48] http://www.w3.org/2001/tag/open-summary.html#URIEquivalence-15
     [49] http://www.textuality.com/tag/uri-comp-4
     [50] http://www.w3.org/2001/tag/open-summary.html#HTTPSubstrate-16
     [51] http://lists.w3.org/Archives/Public/www-tag/2003Feb/0208.html
     [52] http://www.w3.org/2001/tag/open-summary.html#errorHandling-20
     [53] http://www.w3.org/2001/tag/ilist.html#xlinkScope-23
     [54] http://lists.w3.org/Archives/Member/tag/2003Mar/0094.html
     [55] http://lists.w3.org/Archives/Member/tag/2003Mar/0104
     [56] http://www.w3.org/2001/tag/open-summary.html#contentTypeOverride-24
     [57] http://www.w3.org/2001/tag/doc/mime-respect.html
     [58] http://www.w3.org/TR/speech-grammar/
     [59] http://www.w3.org/TR/speech-grammar/#S2.2.2
     [60] http://www.w3.org/2001/tag/open-summary.html#contentPresentation-26
     [61] http://www.w3.org/2001/tag/open-summary.html#IRIEverywhere-27
     [62] http://lists.w3.org/Archives/Member/tag/2003Apr/0074.html
     [63] http://lists.w3.org/Archives/Public/www-tag/2003Apr/0090.html
     [64] http://www.w3.org/2001/tag/ilist#fragmentInXML-28
     [65] http://www.w3.org/2001/tag/open-summary.html#binaryXML-30
     [66] http://lists.w3.org/Archives/Public/www-tag/2003Feb/0224.html
     [67] http://www.w3.org/2001/tag/open-summary.html#metadataInURI-31
     [68] http://lists.w3.org/Archives/Member/tag/2003May/0050.html
     [69] http://lists.w3.org/Archives/Public/www-tag/2003Apr/0151.html
     [70] http://www.w3.org/2001/tag/ilist#xmlIDSemantics-32
     [71] http://www.w3.org/2001/tag/doc/xmlIDSemantics-32.html
     [72] http://www.w3.org/2001/tag/ilist#xmlFunctions-34
     [73] http://lists.w3.org/Archives/Public/www-tag/2003Feb/0309.html
     [74] http://www.w3.org/2001/tag/ilist.html#siteData-36
     [75] http://www.w3.org/2003/06/24-tag-summary.html#abstractComponentRefs-37
     [76] http://lists.w3.org/Archives/Public/www-tag/2003Apr/0089.html

4. Other actions

     * Action IJ 2003/02/06: Modify issues list to show that
       actions/pending are orthogonal to decisions. IJ and PLH making
       substantial progress on this; hope to have something to show in


    Ian Jacobs for Stuart Williams and TimBL
    Last modified: $Date: 2003/06/10 14:39:32 $

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

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