[Minutes] 17 Mar 2003 TAG teleconf (mailing lists, xlinkScope-23, arch of messages, decoupling specs, arch doc)


Minutes of the TAG's 17 Mar teleconf available as
HTML [1] and as text below.

 - Ian

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

                   Minutes of 17 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/17-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 (30min)

    1. Roll call. All present: SW (Chair), TBL, DC, DO, CL, TB, PC, NW,
       RF, IJ (Scribe)
    2. Accepted [8]24 Feb telecon minutes
    3. Acceped this [9]agenda?
       Yes, with addition of discussion on forward references from
       XInclude spec
    4. Next meeting: 24 March. Regrets: TBL. At risk: CL
          + Expect to cover: input from Jonathan Marsh ([10]forwarded by
            Paul Cotton); related to # rdfmsQnameUriMapping-6

      [8] http://www.w3.org/2003/02/24-tag-summary.html
      [9] http://www.w3.org/2003/03/10-tag.html
     [10] http://lists.w3.org/Archives/Public/www-tag/2003Feb/0207.html

  1.1 Meeting planning

     * Resolved: The TAG resolved not to meet face-to-face in Budapest in
       May due to scheduling issues.
       Completd action PC: nform organizers that TAG does not intend to
       meet during that week in Budapest. (Done)
     * The TAG will strive to organize a virtual meeting shortly after
       the WWW Conference.
       Action TBL: Propose June dates (after 4 June). [Also, some
       willingness also to meet before May confs]
     * The TAG expects to discuss its [11]W3C track presentation
     * The TAG expects to discuss its presentation to the AC mid-April.

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

   Not discussed:
     * Proposed 14-15 Nov Japan

  1.2 Mailing list management

     * Completed action SW: Send draft mailing list policy to tag@w3.org.
       (See [12]preliminary announcement and [13]proposed text).
     * [14]Proposal from Paul Cotton for announcement list.

     [12] http://lists.w3.org/Archives/Public/www-tag/2003Feb/0196.html
     [13] http://lists.w3.org/Archives/Member/tag/2003Mar/0053.html
     [14] http://lists.w3.org/Archives/Member/tag/2003Mar/0038.html

     * Incorporate some [15]proposed text from Stuart Williams into the
       [16]tips on communicating with the TAG.
       Action IJ: Incorporate said text. Then, action SW: Send msg to
       www-tag drawing people's attention to revised text.
     * Create a new list (public-tag-announce) for announcements of
       meeting minutes, meeting summaries, findings, new issues, resolved
       issues, and drafts of architecture documents.
       Action IJ: Request list setup; update TAG home page.

     [15] http://lists.w3.org/Archives/Member/tag/2003Mar/0053.html
     [16] http://www.w3.org/2001/tag/#tag-attn

  1.3 Review of input from technical plenary (xlinkScope-23)

   The TAG discussed the [17]Tech Plenary BOF report from Henry Thompson
   that relates to TAG issue xlinkScope-23.

     [17] http://www.w3.org/XML/Group/2003/03/xlink_bof_report.html


          SW: Summary - The Hypertext CG and XML CG should constitute a
          small (six to eight members) joint task force to write a reqs
          document. Question of timeframe; a priori expected commitment
          to the outcome. Spirit of proposal generally accepted.
          DC: I'm sort of tuned out since it looks like nothing will
          happen any time soon.: That doesn't bother me.
          CL: Some sinking feeling at BOF that discussion will go on
          somewhere else.
          TBL: Notes that BOF summary not that inspiring.
          TB: Count me as uninspired. I don't think we'll make the tech
          discussion easier by having it over a reqs doc instead of over
          a solution. What leads anyone to suspect that there is
          consensus out there?
          TBL: Perhaps way to move forward is to require that (1) any
          feature proposed must provide rationale for what cannot be done
          without that feature

          I have come to appreciate requirements documents. They have a
          time and a place. esp in diverse communities that would like to
          learn to talk to each other.

          TB: I don't think we have to do anything (as the TAG). If the
          two CG's think a task force is appropriate, that's great; What
          do we have to offer at this point?
          CL: A statement that there is an architectural hole, for
          NW: I agree with TB. I think individuals might be able to do
          more, but TAG may not be able to.
          DC: One possibility

         1. I asked NW what he thought the ideal solution was. I think
            NW's position was that it would be better to pick one
            arbitrary choice, rather than have N floating around.
         2. TAG could pick one and market it. The TAG exists as a
            marketplace for attention.

          DC: I am not inspired by the technical material, nor that
          picking one will be a substantial advance in the art. But we
          could be a force for unification.
          TB: We tried this and convinced approximately nobody.
          DC: These things take time.
          TB [revision]: I think that it might be productive to invest
          some time to examine the technical issues and let the community
          know what we think. I'm not interested in the work of creating
          task forces.
          SW: I think most of TAG would back one choice as opposed to let
          1k flowers bloom. I have to communicate with two CGs.
          DC: I hear CL and TB saying "let's not close xlinkScope-23
          without further discussion". So I expect SW to tell CGs that we
          expect to address this technically in substance; so we should
          be connected to their discussions (somehow).
          CL: The TAG cares about the results (of the task force)
          Action SW: Draft note for TAG review of comments to two CGs on
          the tone of today's discussion.

   Other feedback from Tech Plenary:
    1. DC: I heard folks say this plenary was good because folks could
       disagree civilly. I think the TAG had some role in establishing
       that norm.
    2. Some discussion on whether to hold more than one TP per year.
    3. [18]PC reported some comments related to the Arch Doc.

     [18] http://lists.w3.org/Archives/Member/tag/2003Mar/0050.html

   DC: I haven't reviewed the tech planary IRC log for TAG suggestions,
   but I tried to watch for TAG stuff real-time and send mail at the

  1.4 Other stuff

     * Action IJ 2003/02/06: Modify issues list to show that
       actions/pending are orthogonal to decisions. IJ is working with
       PLH on this.

2. Technical (60min)

  2.1 New issue? Message passing, a dual of shared state

   [19]Raised by DC, no resolution from TAG.

     [19] http://lists.w3.org/Archives/Public/www-tag/2003Mar/0018.html


          DC: Lots of arch discussions about REST/URIs. But there's
          another category of "conversations"; e.g., "[20]Conversations
          and state." Voice, Web services closer to conversational
          interface. I think that this is discussed enough that the TAG
          should either include in arch doc, do a finding, etc.
          RF: What's the issue?
          DC: People get confused that "if it's not rest-like it
          shouldn't be near W3C."
          TBL: The issue is that "not everything is rest."
          RF: That's not an issue.
          DC: I don't have text to propose to the editor right now.
          SW: I wonder whether placeholder sufficient.

     [20] http://www.w3.org/DesignIssues/Conversations

          what's the difference between an issue and a placeholder in the
          arch doc?

          TB: I find DC's statement of the issue kind of fuzzy. It may be
          on the Web but it's architecture not defined by REST. I'm
          prepared to accept that something could be usefully said in the
          arch doc.
          DC: See gist of [21]Conversations and state
          CL: At a minimum we should say that scope of arch doc is
          limited; could be useful to point out to people when things are
          are outside of scope.
          RF: I don't consider it an issue that there are other
          interaction models on the information space that is the Web.
          TBL: Perhaps we should have an update on W3C Activities for the
          TAG There's a lot of stuff happening in Voice Activity on
          dialogs; they are modeling dialog paths and dialog outcomes.:
          Some Web Services work not using REST either.
          RF: I understand the arguments; I don't understand why this is
          an "issue"; just add to interactions section.
          SW Proposal: Put placeholder in arch doc.
          Action DC: Write some text for interactions chapter of arch
          DC: Don't expect this week.

     [21] http://www.w3.org/DesignIssues/Conversations

  2.2 New issue? Forward references / decoupling specs / IRIs

   Related issues: [22]IRIEverywhere-27

     [22] http://www.w3.org/2001/tag/ilist#IRIEverywhere-27

          Problems with XInclude moving to Rec include normative
          reference to Xpointer, charmod, and [23]IRI spec. (Never mind

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

          (pointer to this thing that's been pending for too long?)

          we said IRIs are good? when/where?

          TBL: Xpointer referenced for issues about frag id; points to
          charmod for XML parsing; points to IRI spec with caveats.

          we said people should prepare for IRI, do it by copy and paste,
          and be ready to eratta once IRI was set in stone
          this seems to be exactly whatthey did

          TBL: XInclude spec says the WG plans to revise spec when IRI
          spec is finished.

          tbl: no IRI in test suite

          TBL: Arch questions - how to decouple the specs?

          (reviewing our records, I find no decisions re

          TBL: No matter how the IRI spec comes out, it won't affect
          reviews of XPointer. But it will affect conformance of
          software. I think that what XInclude authors wrote in their
          spec may not be helpful since it may lead to operability
          problems when the spec is changed.
          NW: I thought I had been told that I could tell Core WG that
          TAG was in favor of IRIs.
          CL: I understood that, too.

          We have decided *exactly* what our records say we have decided,

          so, they did exactly the right think on IRI reference

          CL: IRIs not on Rec track; but is headed to being standard.
          CL: The piece that CL/MD/IJ wrote is now outdated.
          Action CL/IJ: Revise this IRI summary by next week; send to

          Charmod references the IETF I-D IRI

          norm - thanks

          CL: Specs like XML Schema have similar wording; they cut and
          paste - don't make normative ref.

          For the record: The TAG has not made any decisions on
          IRIEverywhere. Hence I'm not party to any advice anybody's
          giving outside the TAG on this issue. I'd much prefer actions
          to advise other groups waited until we'd decided the issue.

          IRI is more mature, not yes at this point so we should trust
          them to do the IRI-related erattum at the appropriate time

          [Examples of other specs doing something similar re: IRIs]

          ok so I believesd we had at least made some decisions, even if
          we had not closed the whole issue

          obviously, I thought we had general agreement as well

          SW: RDF abstract model doc also talks about this with slightly
          different language


          in fact, if asked before this call, I might have believed that
          the issue was open only because we didn't write down what we
          had agreedd to

          norm, that is where I thought we were, too

          *all* issues are only open because we haven't written down what
          we agreed to.

          no, dan, there's more to it if we don't have agreeement, and
          you seem to be asserting that we don't

          all the work is in the writing it down.

   [No resolution]

  2.3 Architecture document


          DC: I would prefer that the[24] 6 Feb draft (21 Feb draft) go
          to TR page.
          IJ: I am frustrated with lack of input on this draft. Not sure
          how to proceed.
          DC: I support TR page publication of 6 Feb draft. If you have a
          new intro, seek specific reviewers.
          IJ: What can I do to get more input?
          DC: We all have limited time; I have to balance where to turn
          my attention. Proposal: Request publication of 6 Feb draft on
          TR page.

     [24] http://www.w3.org/2001/tag/2002/webarch-20030206

          I am focused on URI spec due to IETF meeting on Thursday

          Sorry, I would need to see the differences between these before
          agreeing to backtrack

          IJ: I think the 21 Feb draft is a better intro, even if not
          what it ultimately looks like.
          DC: I'd like to see diagram of specific URI of GET(URI)->
          [People keen on idea of diagram]

          It's a heartbeat. I vote "concur" to publish any draft.

          IJ: I hear three proposals: 6 Feb draft, 21 Feb draft, some
          hybrid with 6 Feb intro
          SW: My preference is for hybrid.
          Action IJ: Draft a new hybrid that incorporates intro of 6 Feb
          draft into 21 Feb version.
          IJ: I will try to get TB okay before requesting publication on
          TR page.
          SW: I am available to look at hybrid draft.

   See also: [25]findings.
    1. [26]21 Feb 2003 Editor's Draft of Arch Doc:
         1. Resolve to request publication of this draft (with
            modifications?) on TR page?
         2. Action DC 2003/02/06: Attempt a redrafting of 1st para under
         3. Action DC 2003/01/27: write two pages on correct and
            incorrect application of REST to an actual web page design
         4. Action DO2003/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. 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". [27]Proposal from TB
            to withdraw the proposal.
         7. See [28]PC's email on feedback from Tech Plenary

     [25] http://www.w3.org/2001/tag/findings
     [26] http://www.w3.org/2001/tag/2003/webarch-20030221
     [27] http://lists.w3.org/Archives/Public/www-tag/2003Feb/0005
     [28] http://lists.w3.org/Archives/Member/tag/2003Mar/0050.html

  2.4 Issues not discussed

     * [29]xlinkScope-23
          + Status report?
     * [30]contentTypeOverride-24
          + See [31]email from DC to Voice Browser WG. Does this resolve
            this issue?
          + Related to TBL's new issue proposal regarding decoupling
     * [32]siteData-36
          + Completed action TB: Post a [33]strawman proposal for
          + Action TBL 2003/02/24 : Summarize siteData-36
     * [34]namespaceDocument-8
          + Next steps on [35]RDDL Proposal from Tim Bray/Paul Cotton
     * [36]xmlFunctions-34
          + Action TBL 2003/02/06: State the issue with a reference to
            XML Core work. Deadline 17 Feb.
     * [37]binaryXML-30
          + Action TB 2003/02/17: Write to www-tag with his thoughts on
            adding to survey.
          + Next steps to finding? See [38]summary from Chris.
     * [39]contentPresentation-26
          + Action CL 2003/02/06: Create a draft finding in this space.
            Deadline 3 March.

     [29] http://www.w3.org/2001/tag/ilist.html#xlinkScope-23
     [30] http://www.w3.org/2001/tag/open-summary.html#contentTypeOverride-24
     [31] http://lists.w3.org/Archives/Public/www-tag/2003Feb/0085.html
     [32] http://www.w3.org/2001/tag/ilist.html#siteData-36
     [33] http://lists.w3.org/Archives/Public/www-tag/2003Feb/0297.html
     [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#xmlFunctions-34
     [37] http://www.w3.org/2001/tag/open-summary.html#binaryXML-30
     [38] http://lists.w3.org/Archives/Public/www-tag/2003Feb/0224.html
     [39] http://www.w3.org/2001/tag/open-summary.html#contentPresentation-26

     * [40]URIEquivalence-15
          + See [41]draft 4. See also [42]email from Larry Masinter on
            xml namespaces.
          + TBL 2003/01/20: Send email to uri@w3.org requesting
            terminology change (regarding definition of "URI").
          + Completed Action TB 2003/02/06: Send URI equiv draft finding
            to uri@w3.org. ([43]Done))
     * [44]rdfmsQnameUriMapping-6
          + Action DC 2003/02/06: Propose TAG response to XML Schema
            desideratum ([45]RQ-23).
     * [46]uriMediaType-9
          + Action DC 2003/02/06: Start discussion on
            discuss@apps.ietf.org, but not urgent
     * [47]RDFinXHTML-35
          + Completed action DC 2003/02/06: Write up a crisp articulation
            of issue RDFINHTML-35. [48]Done
     * [49]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 [50]message from Larry Masinter w.r.t. Web services.
     * [51]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.
     * [52]IRIEverywhere-27
          + Action CL 2003/01/27: Send piece that CL/MD/IJ wrote to
     * [53]metadataInURI-31
          + Action SW 2003/02/06: Draft finding for this one.
     * [54]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.

     [40] http://www.w3.org/2001/tag/open-summary.html#URIEquivalence-15
     [41] http://www.textuality.com/tag/uri-comp-4.html
     [42] http://lists.w3.org/Archives/Public/www-tag/2003Feb/0090.htm
     [43] http://lists.w3.org/Archives/Public/uri/2003Mar/0014.html
     [44] http://www.w3.org/2001/tag/open-summary.html#rdfmsQnameUriMapping-6
     [45] http://www.w3.org/TR/2003/WD-xmlschema-11-req-20030121/#N400183
     [46] http://www.w3.org/2001/tag/open-summary.html#uriMediaType-9
     [47] http://www.w3.org/2001/tag/ilist#RDFinXHTML-35
     [48] http://lists.w3.org/Archives/Public/www-tag/2003Mar/0019.html
     [49] http://www.w3.org/2001/tag/open-summary.html#HTTPSubstrate-16
     [50] http://lists.w3.org/Archives/Public/www-tag/2003Feb/0208.html
     [51] http://www.w3.org/2001/tag/open-summary.html#errorHandling-20
     [52] http://www.w3.org/2001/tag/open-summary.html#IRIEverywhere-27
     [53] http://www.w3.org/2001/tag/open-summary.html#metadataInURI-31
     [54] http://www.w3.org/2001/tag/ilist#fragmentInXML-28


    Ian Jacobs for Stuart Williams and TimBL
    Last modified: $Date: 2003/03/17 22:48:21 $

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

Received on Monday, 17 March 2003 17:52:38 UTC