[Minutes] 7 Apr 2003 TAG teleconf (arch doc, contentTypeOverride-24, namespaceDocument-8, IRIEverywhere-27)


The minutes of the 7 Apr 2003 TAG teleconf are 
available as HTML [1] and as text below.

 - Ian

[1] http://www.w3.org/2003/04/07-tag-summary.html


                   Minutes of 7 Apr 2003 TAG teleconference

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

      [4] http://www.w3.org/2003/04/07-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: NW (Chair), TBL, PC, DO, TB, CL, RF, IJ (Scribe):
       Regrets: SW. Missing: DC.
    2. Accepted [8]31 Mar telecon minutes
    3. Accepted this [9]agenda
    4. Accepted [10]summary of TAG activity with two suggestions:
         1. PC reminder about report to AC in May
         2. CL suggested wording for progress on issues
         3. Action IJ: Send out summary with these changes.
    5. Next meeting: 14 April. No regrets signaled.

      [8] http://www.w3.org/2003/03/31-tag-summary.html
      [9] http://www.w3.org/2003/04/07-tag.html
     [10] http://lists.w3.org/Archives/Member/tag/2003Apr/0007.html

  1.1 Meeting planning

     * The TAG will strive to organize a virtual meeting shortly after
       the WWW Conference. See [11]thoughts from SW on organizing a
       virtual meeting.
       Completed action TBL 2003/03/31: Propose June dates (after 4
       June). (See [12]questionnaire)
       The TAG will try to finalize the date next week after remaining
       TAG participants have completed questionnaire.
     * Upcoming discussions:
          + The TAG expects to discuss its presentation to the AC on 14
            and 21 April.
          + Action IJ: Report to mtg organizer TBL constraint on slot for
            TAG report, then report back to TAG on revised slot.

     [11] http://lists.w3.org/Archives/Member/tag/2003Mar/0082.html
     [12] http://www.w3.org/2002/09/wbs/34270/05%252F06.03/

  1.2 W3C Track Presentation

     * [13]W3C track [30]: "TAG scope"
     * [14]Notes from Paul Cotton

     [13] http://www2003.org/t_www.htm
     [30] http://www.textuality.com/xml/rddl3.html
     [14] http://lists.w3.org/Archives/Member/tag/2003Apr/0010.html

          'what is the tag and why should you care" fits in 30 minutes

          when is the www slot, actually?

          PC suggestion:

         1. scope and role of the TAG
         2. sample findings issued by the TAG and their results
         3. overview of the Web Architecture document

          who wil be there - ian, paul, chris, timbl

          NW: Please reply on email to PC's proposal
          Next week: TAG will finalize who will give which piece of the
          track presentation on 14 April.

2. Technical

    1. [15]Architecture document
    2. [16]contentTypeOverride-24
    3. [17]namespaceDocument-8
    4. [18]IRIEverywhere-27

  2.1 Architecture document

   See also: [19]findings.
    1. [20]26 Mar 2003 Working Draft of Arch Doc:
         1. Action DC 2003/02/06: Attempt a redrafting of 1st para under
            [21]2.2.4 of 6 Feb 2003 draft
         2. Action DC 2003/01/27: write two pages on correct and
            incorrect application of REST to an actual web page design
         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.
         4. Completed 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 CP10. ([22]Done)
            CL: Belongs in section 4.2 of Architecture Document.
         5. Action DC 2003/03/17: : Write some text for interactions
            chapter of arch doc related to [23]message passing, a dual of
            shared state.

     [19] http://www.w3.org/2001/tag/findings
     [20] http://www.w3.org/TR/2003/WD-webarch-20030326/
     [21] http://www.w3.org/2001/tag/2002/webarch-20030206#uri-use
     [22] http://lists.w3.org/Archives/Public/www-tag/2003Apr/0034.html
     [23] http://lists.w3.org/Archives/Public/www-tag/2003Mar/0018.html


          IJ: Who is reading the arch doc?

          NW: I am getting closer to reading it.

          I have been reading it this week, yes

          TBL also reading arch doc.

  2.2 contentTypeOverride-24

     * [24]contentTypeOverride-24
          + See [25]email from DC to Voice Browser WG.
          + Completed action IJ 2003/03/24: Draft up some language; make
            connection to error-handling issue. TAG position with
            rationale why to not override server value of content type.

     [24] http://www.w3.org/2001/tag/open-summary.html#contentTypeOverride-24
     [25] http://lists.w3.org/Archives/Public/www-tag/2003Feb/0085.html
     [26] http://www.w3.org/2001/tag/doc/mime-respect-20030405.html

          IJ: I completed the action item, but haven't made the [27]draft
          public. I intend to publish this in a week; please review.
          CL: Some of the material was in an earlier finding. Please link
          back to [28]Internet Media Type registration, consistency of
          IJ: Yes, I agree. I'll put publication of this on agenda for
          next week

     [27] http://www.w3.org/2001/tag/doc/mime-respect-20030405.html
     [28] http://www.w3.org/2001/tag/2002/0129-mime

  2.3 namespaceDocument-8

     * [29]namespaceDocument-8
          + Next steps on [30]RDDL Proposal from [31]Tim Bray/Paul Cotton

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


          TB: I have an action to fix this up to ensure that it's valid,
          modularized xhtml. Two substantive issues before the TAG:

         1. Do we support this version of RDDL on a technical basis?
         2. How do we move it forward?

          TBL: I think that the TAG is not set up to be a WG at this
          time; Rec track docs would be quite a drain on resources at
          this time. If this were a draft, I think at this time it would
          be better to fork off another WG.

          Please see
          for my view.

     [32] http://lists.w3.org/Archives/Member/tag/2003Apr/0012.html

          TBL: Another possibility is to say "we don't think this is
          contentious, we don't have time to get review, we'll publish as
          a Note.": Then, if picked up, then can put on Rec track. Or if
          not used because of problems, move to a WG for more work.
          PC: On this front, I think the TAG should "ask permission" and
          not "ask forgiveness". Therefore I would like to propose the

         1. we publish our proposal for namespacedocument-8 [$1\47] as a
            Note ASAP
         2. we specifically request input for the AC membership at the
            May AC on how the content of this Note if and should be
            progressed to Recommendation track.

          PC: We should negotiate this precedent with the AC. With simple
          change by TB, we could publish as Note quickly and get ac
          TB: I think I agree with TBL and PC; don't want to be sloppy to
          respond formally to public input. What about publishing this as
          a finding? I could also see publishing as a Note.

          Chris, you wanted to talk about life after rec, testsuites, and
          other resource suckers

          CL: Lots of responsibilities for Rec track work (e.g., test
          suites, life after Rec, etc.) I support publication as a
          NW: I agree with PC (publication as a Note)

          we could still ask the AC if the finding should go on the rec
          track and if so who should do it would work

          NW: I think that findings have more stature; people used to
          seeing docs from TAG at this point. People are more used to
          seeing spec-like things as Notes.
          IJ: Note more spec-like; TR page as location for document
          likely to get more attention.: I lean slightly towards Note

          timbl_, you wanted to ask about links from

     [33] http://www.textuality.com/xml/rddl3.html

          Action TB: (1) Clean up messy section 4 of RDDL draft and (2)
          Investigate and publish a canonical mapping to RDF.
          Summarizing: TAG doesn't think that Rec track best option for
          now (at least without consulting the AC).
          TBL: I think finding is inappropriate; people expect a certain
          genre of thing in a finding. This is Note-like. We could
          publish a finding explaining why the Note is good....
          TB: Can you have a Note that says "This represents the
          consensus of...."
          IJ: Yes.

          What Norm said

          finding can be short, but should still exist

          Proposed: Plan is to publish TB's revised RDDL document as a
          W3C Note. Status section would say that it represents the
          consensus of the TAG.
          CL: The finding would say why the solution is desirable.
          IJ: I think that rationale would be better in the document.

          Where do we say that users of namespaces SHOULD use the
          suggested format.

          CL: I'd like each issue to close with a finding.

          its a consistency thing

          TB: Current language in Note does not say "namespaces SHOULD
          use the suggested format." I would be fine to say that, but
          don't think it needs it.

          Current doc says "A Resource Directory is designed to be
          suitable for service as the body of an entity returned by
          dereferencing a URI serving as an XML Namespace name."

          TBL: I hear PC saying put language spec in a Note, put
          recommendations on usage in a finding. I feel that we can put
          the RDDL Note forward, but I agree where there will be
          applications where people will use XML or RDF schema. I don't
          want to force people to use it.
          NW: I agree with CL to use finding to answer finding, publish
          spec in Note.

          OK, I can go with the the 2-doc solution

          IJ: I can go with the 2-doc solution.
          Proposal: TAG expects to publish RDDL Spec as a Note (status
          section to indicate consensus of TAG), and to produce a finding
          to answer question of namespaceDocument-8, namely that groups
          SHOULD use RDDL.
          TBL: I think we should say that RDDL is a good example (don't
          say "SHOULD" in finding; just indicate RDDL as a good example).

          I think we should say that RDDL should be used.

          Proposal: TAG expects to publish RDDL Spec as a Note (status
          section to indicate consensus of TAG), and to produce a finding
          to answer question of namespaceDocument-8.

          ok by me

          TB: I'm optimistic that in the finding we'll find consensus on

          I don't want to recommend RDDL any more than we recommend XML,
          RDF or SVG

          Proposal: TAG expects to publish RDDL Spec as a Note (status
          section to indicate consensus of TAG that this is a suitable
          representation of a resource), and to produce a finding to
          answer question of namespaceDocument-8 (with some sort of
          pointer to the RDDL spec).
          Proposal: TAG expects to publish RDDL Spec as a Note (status
          section to indicate consensus of TAG that RDDL is a suitable
          format for representations of an XML namespace), and to produce
          a finding to answer question of namespaceDocument-8 (with some
          sort of pointer to the RDDL spec).
          Resolved: TAG expects to publish RDDL Spec as a Note (status
          section to indicate consensus of TAG that RDDL is a suitable
          format for representations of an XML namespace), and to produce
          a finding to answer question of namespaceDocument-8 (with some
          sort of pointer to the RDDL spec).
          Action TB: Work on RDDL Note.
          Action PC: Work on TAG finding.

  2.4 IRIEverywhere-27

     * [34]IRIEverywhere-27
          + Action CL 2003/03/31: Revised position statement on use of
            IRIs. See [35]email from CL on next steps.

     [34] http://www.w3.org/2001/tag/open-summary.html#IRIEverywhere-27
     [35] http://lists.w3.org/Archives/Public/www-tag/2003Apr/0033.html

          I have to step away for a few minutes.

          CL: I'd like more discussion this week; deadline 21 April? Also
          need to convey to Martin the desirability of seeing
          [36]http://www.w3.org/International/iri-edit/ updated to
          include iDNS and published as draft 4, and to move to RFC soon.
          I'd like to address question of 'blessed wording' regarding IRI
          that three XML-related specs can use to get to Proposed Rec.

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

          Kanji example in

     [37] http://www.tbray.org/ongoing/When/200x/2003/03/31/IRI

          TBL: I think there is a fundamental question that has not been
          resolved, and is causing a lot of tension.: Whether,
          fundamentally, the fundamental string is the URI, or whether we
          are dispensing with URIs in favor of Unicode strings instead.

          position A says IRI is a way of talking about URI
          position B says IRI is the real thing and URI is a subset that
          should go away

          TBL: I was under the impression during development of IRIs,
          that the model was position A. I think the TAG needs to adress
          this bifurcation (A v. B)
          TB: I agree with the TBL and CL characterization of the heart
          of the issue.

          and please lets get to blessed text after we have discussed

          TB: "Is any URI an IRI?" I think the answer is No; lots of
          sloppiness about hexifying.

          strongly disagree with TimBray

          TB: I think IRIs need to be rigid and deterministic about when
          hexifying is used, and that the mapping (to URI) process be
          CL: I don't think it's true that all URIs are IRIs.

          [Some discussion of equivalence measures around hexifying]

          CL: It does not follow that the URI version of an IRI is the
          same as that IRI. It does not follow that the URI version of an
          IRI is the same as that IRI in all cases: same when you
          dereference; not the same in e.g., namespace comparisons.
          NW: Why inappropriate to convert to URI before comparison?
          CL: A number of specs don't do it that way; they do simple
          string matching in a number of specs. Therefore, not reasonable
          in practice to require conversion to URI. E.g., you have to
          have a kanji character and upper case hex and lower case hex to
          be the same.

          We really need to do this in a room with a whiteboard

          CL: Too much water to push uphill (especially when extra
          processing doesn't get you much).

          timbl_, you wanted to argue that theis is relatively little
          water to push up hill

          TBL: I've been there too.... I was convinced of CL's argument,
          but upon further reflection believe it's untenable.: Suppose
          that identifiers are unicode strings and you don't have to
          canonicalize them to compare them. There is ten years of
          software using 7-bit fields for this quantity.

          I need to step out for 3-4 min.

          TBL: If suddenly you allow namespaces that can differ in 7-bit
          systems but not in 8-bit systems. Changing the XML spec is
          relatively easy. You have a transition strategy: ask them to
          canonicalize namespace IDs and xpaths. During the interim, the
          only time things actually fail is when people use things that
          only differ in case of hex encoding. So this is a corner case.
          Easier to move to full canonicalization and full equality and
          to be consistent with 10 years of code and fix latest
          CL: I strongly disagree.
          TB: I'm not sure that CL and I disagree that much. In terms of
          URIs, it's a fact that everyone uses string comp in namespace
          applications. We have ample evidence that this is prone and
          shakey to failure, but people do it anyway.

          everyone uses string comparison in namespace comparisons, and
          in xpath. and in xml query. and ....

          TB: One reason has to do with hex-encoding. We can remove that
          sloppiness in the IRI spec; but we'd have to abandon the
          insistence that every URI is an IRI.
          TBL: I hear TB proposing that IRIs are always canonical.

          Chris, you wanted to point out that I really, really want to
          talk about blessed text in the next 20 minutes

          I'm back.

          TBL: Are you saying, CL, that browsers that use hex encoding
          are wrong?
          CL: Yes, they are doing it too early. They should do when they
          send over HTTP transport.
          TBL: If you are telling me that the encoded and unencoded forms
          are equivalent....
          CL: Yes.
          RF: When a robot takes advantage of some heuristic, this is not
          for the purpose of determining equivalence of the identifier;
          it's equivalence of an operation.
          TBL: Each algorithm in the deployed software, though, is using
          a different piece of the URI spec for its heuristics.
          RF: There is a reason to create an equivalence relationship
          between IRIs and URIs. That there are other mechanisms that
          don't respect that equivalence is irrelevant. I agree with TBL.
          NW: I think that TB is right - the key to make this all fit
          together is to say "Not all URIs are IRIs, and you define
          mappings that are reversible"

          deprecated subset of URIs

          [On text about IRIs in specs at this point]
          CL: Should we be in the business of producing parts of specs
          that have guarantees associated with them, or not.: Or do we
          say "Here's our best guess, do the best you can to prepare
          something for the Director."

          timbl_, you wanted to say we should respond and we should not
          suggest the result has papal infallibility.

          TBL: If we are talking about this, we owe people a response,
          but without any guarantees.

          agree about the papal infallibility

          TB: see language in xml 1.1...hmmm, doesn't say much.
          CL: There is language in schema spec as well. People could
          point to that (It's a Rec)
          TB: I think the anyURI type is underspecified. Last time I
          looked, there were very few syntactic restrictions on what you
          can put in an anyURI. I don't think that that's a good
          TBL: How about if we tell people to refer to the IRI draft.
          Then we explain to people what that means: When you refer to
          the IRI spec, you take on that %7e and %7E are the same.

          this is the option A, push water uphill argument

          TBL: That gets the XML specs off the hook. We need to explain
          that, the syntax and semantics are defined by URI specs.
          NW: Core WG wants to say that these things are IRIs, not URIs.

          Core WG wants to say these things are IRIs

          TB: I think that it's clear that we probably can't solve their
          problem for them.: IRI, though the right answer, isn't done.
          TBL: Propose that specs continue to be well-defined in terms of
          URIs, and only as well-defined as the IRI spec currently is.
          URI conformance + xml namespace conformance will give you this
          NW: A lot of existing software will no longer be conformant.
          CL: XML Namespace software will break.
          RF: But IRIs won't look in the future like they look today.
          IRIs will change to support IDNA.
          NW: If you do what TBL just said, then you have to use URI
          comparison and not string comparison.
          RF: Then use the field, define in the other specs as CDATA, and
          forget about it.

          CL: I have an action to write this up.

          I cannot complete writing this up
          all proposed solutions have vehement objections

          NW: IJ: please move the question of text that WGs may include
          in specifications up on the agenda next week.

   No resolution.

  2.5 Other issues that have associated action items

     * [38]URIEquivalence-15
          + SW proposal: Track RFC2396bis where [39]Tim Bray text has
            been integrated. Comment within the IETF process. Move this
            issue to pending state?
     * [40]xmlIDSemantics-32
          + See [41]Chris Lilley draft finding
     * [42]abstractComponentRefs-37
     * [43]xlinkScope-23
          + Status report?
          + See [44]draft, and [45]SW message to CG chairs.
     * [46]siteData-36
          + Action TBL 2003/02/24 : Summarize siteData-36
     * [47]xmlFunctions-34
          + Action TBL 2003/02/06: State the issue with a reference to
            XML Core work. See [48]email from TimBL capturing some of the
     * [49]binaryXML-30
          + Action TB 2003/02/17: Write to www-tag with his thoughts on
            adding to survey.
          + Next steps to finding? See [50]summary from Chris.
     * [51]contentPresentation-26
          + Action CL 2003/02/06: Create a draft finding in this space.
            Deadline 3 March.
     * [52]rdfmsQnameUriMapping-6
          + Action DC 2003/02/06: Propose TAG response to XML Schema
            desideratum ([53]RQ-23).
     * [54]uriMediaType-9
          + Action DC 2003/02/06: Start discussion on
            discuss@apps.ietf.org, but not urgent
     * [55]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 [56]message from Larry Masinter w.r.t. Web services.
     * [57]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.
     * [58]metadataInURI-31
          + Action SW 2003/02/06: Draft finding for this one.
     * [59]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.

     [38] http://www.w3.org/2001/tag/open-summary.html#URIEquivalence-15
     [39] http://www.textuality.com/tag/uri-comp-4
     [40] http://www.w3.org/2001/tag/ilist#xmlIDSemantics-32
     [41] http://www.w3.org/2001/tag/doc/xmlIDSemantics-32.html
     [42] http://www.w3.org/2003/04/24-tag-summary.html#abstractComponentRefs-37
     [43] http://www.w3.org/2001/tag/ilist.html#xlinkScope-23
     [44] http://lists.w3.org/Archives/Member/tag/2003Mar/0094.html
     [45] http://lists.w3.org/Archives/Member/tag/2003Mar/0104
     [46] http://www.w3.org/2001/tag/ilist.html#siteData-36
     [47] http://www.w3.org/2001/tag/ilist#xmlFunctions-34
     [48] http://lists.w3.org/Archives/Public/www-tag/2003Feb/0309.html
     [49] http://www.w3.org/2001/tag/open-summary.html#binaryXML-30
     [50] http://lists.w3.org/Archives/Public/www-tag/2003Feb/0224.html
     [51] http://www.w3.org/2001/tag/open-summary.html#contentPresentation-26
     [52] http://www.w3.org/2001/tag/open-summary.html#rdfmsQnameUriMapping-6
     [53] http://www.w3.org/TR/2003/WD-xmlschema-11-req-20030121/#N400183
     [54] http://www.w3.org/2001/tag/open-summary.html#uriMediaType-9
     [55] http://www.w3.org/2001/tag/open-summary.html#HTTPSubstrate-16
     [56] http://lists.w3.org/Archives/Public/www-tag/2003Feb/0208.html
     [57] http://www.w3.org/2001/tag/open-summary.html#errorHandling-20
     [58] http://www.w3.org/2001/tag/open-summary.html#metadataInURI-31
     [59] 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 Norm Walsh and TimBL
    Last modified: $Date: 2003/04/07 22:36:12 $

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

Received on Monday, 7 April 2003 18:42:39 UTC