W3C home > Mailing lists > Public > www-tag@w3.org > March 2004

[Minutes] 22 March 2004 TAG teleconf (charmodReview-17, LC-klyne26, LC-kopecky5, LC-kopecky6, LC-booth3, LC-schema17)

From: Ian B. Jacobs <ij@w3.org>
Date: Tue, 23 Mar 2004 18:35:29 -0500
To: www-tag@w3.org
Message-Id: <1080084929.4620.10.camel@seabright>

Minutes of the TAG's 22 March 2004 teleconf are available as
HTML [1] and as text below.

 _ Ian

[1] http://www.w3.org/2004/03/22-tag-summary.html

                  Minutes of 22 March 2004 TAG teleconference

1. Administrative (20min)

    1. Roll call: All present - SW, MJ, DC, RF, NW, IJ, TBL, CL, PC.
    2. Accepted the minutes of the [7]2 Mar ftf meeting
    3. Accepted the minutes of the [8]15 Mar teleconference
    4. Accepted this [9]agenda
    5. Resolved: The TAG will not meet 12 April.
    6. 19 April: CL, TBL at risk.
    7. 26 April: IJ at risk.

      [7] http://www.w3.org/2004/03/02-tag-summary.html
      [8] http://www.w3.org/2004/03/15-tag-summary.html
      [9] http://www.w3.org/2004/03/22-tag.html

  1.1 Confirmation of ftf meeting 12-14 May

    1. The TAG confirmed its expectation to meet 12-14 May in Boston.
    2. Regrets: SW. Possible regrets: RF. Expect to attend: PC, NW, TBL,
       MJ, IJ, CL. Expects to participate, possibly by phone: DC.
    3. NW and PC expect to share the Chair role.

  1.2 Upcoming vacations, schedule?

    1. SW: Regrets from 5-12 April.
    2. Meet 12 April?

2. Technical (70min)

   See also [10]open actions by owner and [11]open issues.

     [10] http://www.w3.org/2001/tag/actions_owner.html
     [11] http://www.w3.org/2001/tag/issues.html?view=normal&closed=1

  2.1 Publication of Qname finding?

     * [12]qnameAsId-18
         1. Completed action NW 2004/03/15: Publish [13]Using Qualified
            Names. (QNames) as Identifiers in Content as an approved TAG
            finding. ([14]Done)

     [12] http://www.w3.org/2001/tag/issues.html#qnameAsId-18
     [13] http://www.w3.org/2001/tag/doc/qnameids-2004-01-14
     [14] http://lists.w3.org/Archives/Public/www-tag/2004Mar/0062.html

  2.2 Internationalization Issues (charmodReview-17)

   See [15]25 Feb 2004 WD of Charmod Fundamentals
     * [16]Review by Tim Bray (and following thread)
     * Relation to [17]charmodReview-17?
         1. [18]actions
         2. TAG finding related to adoption of Charmod? See [19]mail from

     [15] http://www.w3.org/TR/2004/WD-charmod-20040225/
     [16] http://lists.w3.org/Archives/Public/www-tag/2004Mar/0007.html
     [17] http://www.w3.org/2001/tag/issues.html#charmodReview-17
     [18] http://www.w3.org/2001/tag/actions.html#charmodReview-17
     [19] http://www.w3.org/mid/361483C6-96E6-11D7-9C47-000393914268@w3.org

   Action SW 2004/03/15:  Negotiate an extension of ideally 2 weeks with
   I18N WG for the review of CharMod. ([20]Proposed).

     [20] http://lists.w3.org/Archives/Member/tag/2004Mar/0042.html

          Three pieces of information (links are Member-only)

         1. [21]Review of Charmod
         2. [22]Review of Charmod part 2
         3. On IRIs

     [21] http://lists.w3.org/Archives/Member/tag/2004Mar/0041.html
     [22] http://lists.w3.org/Archives/Member/tag/2004Mar/0075.html

          CL: Exec summary is: except where noted we are satisfied. I'd
          like to discuss some minor issues during this call.


     LC Comment C004 [S] Specifications of protocols and APIs that
     involve selection of ranges SHOULD provide for discontiguous
     selections, at least to the extent necessary to support
     implementation of visual selection on screen on top of those
     protocols and APIs.

          I still feel that there is ambiguity there which would be
          removed by saying "discontiguous logical selections", which is
          the type of discontiguity needed for visual selection.

          Is "selection" defined?

          How does this relate to web architecture?

          CL: I made this comment before. They improved the text. But
          this one conformance requirement has the same wording. Yes,
          selection is defined.

          Including selection in the DOM for accessibility. Second issue:
          it also removes an existing use (encoding of pi or symbol
          fonts); on the one hand this is good because inline graphics
          should be used for graphics, and it says so.

     C069 [C] Content SHOULD NOT misuse character technology for
     pictures or graphics.
     C068 [S] Specifications SHOULD allow the inclusion of or reference
     to pictures and graphics where appropriate, to eliminate the need
     to (mis)use character-oriented mechanisms for pictures or graphics.
     On the other hand, I worry that this might encourage people to
     encode pi or symbol fonts on the ascii range, which is worse than
     using the PUA! The spec could explicitly discuss this case.

          CL: I haven't suggested alternative wording; just expressed a
          TBL: I suggest you propose wording for them to include.

          timbl says to send them wording

          Action CL: Suggest wording to I18N WG regarding C068.
          PC: I'll second both items.
          SW: Propose to adopt CL's two messages (as amended) as the core
          of our response to the I18N WG.
          CL: Our comments on the new last call document would be limited
          to those two above. [We haven't discussed IRIs yet.]
          RF: Support CL's comments thus far.
          SW: Propose to thank CL for his efforts and to make his two
          comments on behalf of the TAG. Objections? Abstentions?

          I abstain; I'm happy for Chris to send these comments, but I
          have trouble relating them to our webarch work.

          Resolved: TAG supports CL's statements (DC abstaining).

    2.2.1 Should text on IRIs be part of Charmod Fundamentals or in a separate

          See my [23]email: IRI section needs too much testing to go in

     [23] http://lists.w3.org/Archives/Member/tag/2004Mar/0057.html

          CL: DC also stated that there was insufficient consensus in the
          community on IRIs. IRIs already referenced in XML Schema, XML
          Namespaces 1.1, XML 3E, XPointer, and XLink. All of those specs
          fill in the blank where URIs say "convert the bytes as
          follows". They add "convert the characters to bytes as
          DC: I still don't think it's appropriate to recommend IRIs with
          a blanket statement.
          CL: They have been In a bunch of recs back to html 4
          DC: As CL stated, IRIs have been in a number of
          Recommendations, back to HTML 4. I think that there are still
          problems w.r.t. HTML, RDF, Schema, etc. I still think that the
          IRI stuff doesn't belong in the same spec that says "text is a
          sequence of characters".
          RF: I don't have much to add beyond what I said on the list. I
          don't consider IRIs to be necessary, let alone fundamental. I
          don't consider recommending them as a fiat to be useful or
          CL: Charmod distinguishes characters, bytes, and glyphs (and
          when to use those terms). We have a finding about when to use
          GET. This involves putting text in a URI. Since text is not
          restricted to ascii, you have to say what to do. IRIs say what
          to do, URIs don't.
          RF: There's text in RFC2396bis about this.

          IJ: Is that text new?

          (it's new to me)
          RF: It's new since RFC2396; was added in approximately the last
          six months. The domain component specifically requires that any
          encoded chars be in UTF-8 prior to percent-encoding. Talks
          about [24]Punycode by reference. (The encoded format for IDNA).
          I don't consider the IRI spec to be referenceable for
          conformance; it is going to have to change each time the URI
          spec changes. It's just not well-baked enough.
          DC: That applies to URIs as well as IRIs: the text of the URI
          spec is just as much at issue as the text of the IRI spec.

     [24] http://www.ietf.org/rfc/rfc3492.txt


          RF: People should use URIs since there is an operable spec;
          there isn't for IRIs.

          sure there is; several W3C recs have them

          RF: The changes to the URI spec don't change the technology
          much, just the description of the technology. Question is at
          what point IRI gets converted to a URI, if ever.
          CL: We told I18N WG to convert to URI before just before
          dereference (if the protocol requires).
          DanC, you wanted to suggest that the TAG doesn't have consensus
          on whether section 7 of the charmod spec is OK or not; my
          comment has been sent. I'm OK to just leave it at that

          DC: I don't hope to convince CL. It's ok we don't have
          consensus, that's life.
          TBL: I don't see that there's a nice set of test cases.

          I'm willing to argue the point, but I don't insist on using the
          meeting time that way.

          TBL: There are questions on the list about whether this or that
          is a valid URI/IRI. People don't have the answers. I don't see
          a valid set of test cases.
          [Discussion of whether test cases required at this time by W3C
          PC: We had request that the I18N folks split the spec into
          three pieces. I still think that's the right approach. I agree
          with CL's points, but he's also hypothesizing that the
          fundamental parts could be held up in CR while the IRI parts
          are implemented.

          does anybody know whether they're going to CR or PR next? I'd
          like the fundamentals less IRIs to go to PR.

          TBL: +1 to going straight to PR

          DC: +1 to going straight to PR.
          PC: I think the community would benefit by fundamental bits
          getting to Rec sooner.

          CL: There are [25]beginnings of tests.

     [25] http://www.w3.org/International/tests/sec-idn-1.html

          [26]http://example.org/~user, [27]http://example.org/%7euser,
          [28]http://example.org/%7Euser are not equivalent under this
          definition. In such a case, the comparison function MUST NOT
          map IRIs to URIs, because such a mapping would create
          additional spurious equivalences."

     [26] http://example.org/~user,
     [27] http://example.org/%7euser,
     [28] http://example.org/%7Euser

          DC: I've put forth a proposal that PC has seconded: Ask the
          I18N WG to remove the part on IRIs and move the rest forward.

          I am willing to keep arguing.

          Straw Poll: Who supports removing IRIs and moving forward? TBL,
          DC, PC, RF, SW, NW, MJ. Does not support: CL.

          TBL: I think CL underestimates the difference in maturity of
          the two parts of the technology. The charmod fundamentals
          (bytes, characters, etc.) is much more mature than the
          complicated relationship between specs (URIs, which is
          changing, IDNs, and IRIs, also changing).

          IRI deals *exactly* with 'converting characters to bytes'.

          TBL: I can see lots of discussion leading to changes to part
          about IRIs. It's a pity to hold the rest of the spec back,
          which is pretty much agreed on.

          I have been putting tests together over the weekend, in fact.

          CL: I'd like to articulate why I think the IRI part should move
          forward with the rest of the spec. Goal is single WWW.
          Continuing to put this off creates a significant fragmentation
          risk. Some countries will develop their own standards.


     [29] http://www.circleid.com/article/436_0_1_0_C/

          +1 to CL's assessment of risk.

          TBL: Why does splitting the spec necessarily "put if off".
          CL: Korea has registered 141K I18N Domain names. Japan has
          registered 63K domain names. 350,000 international domain names
          registered already. "In less than a month of going live, IDN's
          already represent 19% of the total .com and .net domains in
          Korea and around 14% in Japan."

          The solution to technical uncertainty is not political

          My vote for the split does not say that the IRI-only work could
          not progress to Last Call rapidly. I just want it separated so
          that the Fundamental part can breeze through and be done.

          CL: If we keep putting this off to future work, we risk
          fragmentation. Better to get this part of the spec out now.
          Revise it later if necessary (the usual path for specs).

          SW: Two things (1) Confusion about IRIs - replacement for URI
          as the Web's identification mechanism versus IRIs as
          presentation format for URIs. I don't think the IRI spec is
          clear on which direction it is taking. I agree (with RF) that
          it will be harder to deploy IRIs if they are URI replacements.
          The IRI spec is going through the IETF process. It has not
          completed its progress yet. I don't see that a normative ref
          from Charmod will help it make progress.
          PC: I'd be happy for the I18N WG to move the IRI spec to LC as
          quickly as possible. I just don't want to accept the risk of
          linking it with more fundamental material and slowing it down.

          I understand and support the 'breeze through' part

          timbl, you wanted to ask why Chris feels that splitting this
          spec it to delay the second part. I don't see that. Also, to
          suggest that the IDN-URI-IRI connection is not clear. Assuming
          the encoding of the DNS part of a URI is done differently to
          the test of it, then this is scheme-dependent.

          But there are 350,000 test cases already, in one month

          TBL: I think there will be snags. We should encourage people to
          make tests and pursue this rapidly.

          Chris, you wanted to talk about what charmod actually says
          about IRI

          CL: Remaining of Charmod spec directly to PR?
          DC: +1
          PC: +1
          DC: I strongly recommend skipping CR for stuff other than
          section 7 on iris.

          TBL: Do you have test suites and implementation experience for
          normalization form C?

          I've seen sufficient tests for normal form C

          OK I withdraw my No vote and agree with the majority so we now
          have consensus.

          TBL: I haven't heard anything that suggests that an
          implementation report and an interop report wouldn't be fairly

          Good job, Chris. Good effort making sure you understood the
          other side of the argument.

          thanks, Paul

          thanks, chris

          IRI section needs too much testing to go in Fundamentals

     [30] http://lists.w3.org/Archives/Public/www-i18n-comments/2004Mar/0012.html

          Resolved: TAG supports [31]LC comments from Dan Connolly.
          No objections or abstentions.

     [31] http://lists.w3.org/Archives/Member/tag/2004Mar/0057.html

          Action CL: Write up TAG's complete LC comments and send them to
          the I18N WG (cc'ing www-tag).

  2.3 Web Architecture Document Last Call

    1. [32]Last Call issues list ([33]sorted by section)
    2. [34]Annotated version of WebArch
    3. Archive of [35]public-webarch-comments
    4. [36]List of actions by TAG participant
    5. Additional actions
         1. Action IJ 2004/02/09: Incorporate editorial suggestions (see
            minutes of that meeting for details).

     [32] http://www.w3.org/2001/tag/2003/lc1209/issues.html
     [33] http://www.w3.org/2001/tag/2003/lc1209/concerning.html
     [34] http://www.w3.org/2001/tag/2003/lc1209/webarchWithIssues.html
     [35] http://lists.w3.org/Archives/Public/public-webarch-comments/
     [36] http://www.w3.org/2001/tag/2003/lc1209/actions_owner.html

   Actions 2004/03/15 (due 25 March?) to review sections:
     * TBL: I volunteer 2 hours starting at start of section 2
     * Roy: I volunteer to look at section 2
     * Norm: I volunteer for section 3
     * Stuart: I volunteer starting at section 2.3
     * Mario: I will look at section 4


          SW: Any significant progress?
          CL: I suggest that Mario send his own LC comments in to the TAG
          (he has new last call comments).
          RF: I have received TBL's comments on URI spec; haven't
          incorporated them yet.: I'll review them carefully and ping

          Thanks, Roy.

          SW: How to make progress on LC comments?
          CL: Now that I'm done with IRI stuff, I can make progress this

    2.3.1 Review of section 4.5.7

   The tag reviewed an [37]annotated version of the Arch Doc

     [37] http://www.w3.org/2001/tag/2003/lc1209/webarchWithIssues.html

   [38]Issue klyne26: Transcoding allowing by some or all intermediaries?

     [38] http://www.w3.org/2001/tag/2003/lc1209/issues.html#klyne26

     The statement "Web intermediaries are allowed to "transcode ..."
     seemed to me to be rather broadly applied here. Is there a
     specification that asserts this in general? If not, I think the
     comment should be constrained to something like "in some Web
     applications, intermediaries are allowed to transcode.

          The statement "Web intermediaries are allowed to "transcode
          ..." seemed to me to be rather broadly applied here. Is there a
          specification that asserts this in general? If not, I think the
          comment should be constrained to something like "in some Web
          applications, intermediaries are allowed to transcode.

          CL: +1 to Graham's comment.
          CL: I think the mime spec talks about text/* in general.

          We need to add a reference to the text/* media type description

          DC: I propose to move on since CL has already committed to
          commenting this section.

    2.3.2 Review of section 4.5.6

   [39]Issue kopecky6

     [39] http://www.w3.org/2001/tag/2003/lc1209/issues.html#kopecky6

          TBL: Icon for "bug in the architecture"? Propose that this is
          editorial - see tag issue 32, which alas is still open.
          DC: Seconded.

          so we need to clarify that this is an open issue, not solved

          DC: I look forward to a proposal from IJ regarding issue
          IJ: I can propose text to make their example more explicit in
          the arch doc.

     [40] http://www.w3.org/2001/tag/2003/lc1209/issues.html#schema20

          I suggest adding one paragraph (conclusion) from the finding,
          rather than just the reference.


     [41] http://www.w3.org/TR/2003/REC-xptr-framework-20030325/#shorthand

          TBL: We have an ordered list about three types of processing.
          The comment also has a bulleted list. Try to make the two lists
          line up.
          DC: IJ need only say more loudly "We are not finished"

    2.3.3 Review of section 4.5.5

   [42]Issue kopecky5

     [42] http://www.w3.org/2001/tag/2003/lc1209/issues.html#kopecky5

          DC: I am willing to reply to the reviewer and ask for
          Action DC: Seek clarification on kopecky5: 4.5.5 More info on
          qnames, fragids, ns docs

    2.3.4 Review of section 4.5.4

   [43]Issue booth3: NS document as definitive source of info on

     [43] http://www.w3.org/2001/tag/2003/lc1209/issues.html#booth3

          IJ: If we say anything, would be "authoritative" (used in
          metadata finding).
          CL: There seem to be two things:

         1. If you find stuff there, it's "definitive"
         2. Don't say "If there's nothing there, it has no meaning"

          TBL: We have used the term "authoritative".

          I'm OK to demote booth3 to editorial

          special case of authoritative metadata

          IJ: We don't say that/when the "representation data" is
          authoritative; we only talk about metadata. +1 to booth3 being
          editorial and that deeper issues are elsewhere.
          Action IJ: Propose wording to the TAG for booth3.

    2.3.4 Review of section 4.5.3

   [44]Issue schema17

     [44] http://www.w3.org/2001/tag/2003/lc1209/issues.html#schema17

          "Namespaces in XML" [XMLNS] provides a mechanism for
          establishing a globally unique name that can be understood in
          any context. This is a false statement and should not be
          continued to be repeated."

          its false *because* ....??

          RF: You can just say "globally unique names"
          DC: right "in any context" adds nothing. Saying "can be
          understood" is a red flag.

          I concur. s/ that can be understood in any context//

          I agree that 'understood' is a whole other issue and
          unjustified here

          TBL: XMLNS provides a mechanism for associating a tag with a
          pair of a URI and a local name.

          a tag?
          s/tag/element or attribute name/

          TBL: Doesn't flow so well...
          DC: The paragraph starts with points on naming conflicts. Talks
          about using URI scope to disambiguate.

   [No conclusion on 4.5.3 issues yet]


   The TAG did not discuss issues below this line.

  2.4 TLDs and content filtering?

    1. See [45]question from DJW

     [45] http://lists.w3.org/Archives/Public/www-tag/2004Mar/0027.html

  1.1 Review of open action items related to issues

   The TAG expects to review the list of [46]open actions by owner and to
   close any that are obvious to close. TAG participants are encouraged
   to review this list before the meeting, as well as other action items
   listed in this agenda.

     [46] http://www.w3.org/2001/tag/actions_owner.html

3. Status report on these findings

   See also [47]TAG findings
     * [48]abstractComponentRefs-37:
          + 30 Oct 2003 draft finding "[49]Abstract Component References"
     * [50]contentPresentation-26:
          + 30 June 2003 draft finding "[51]Separation of semantic and
            presentational markup, to the extent possible, is
            architecturally sound"
     * [52]metadataInURI-31
     * [53]siteData-36
          + "[54]There is no such thing as a Web site"

     [47] http://www.w3.org/2001/tag/findings
     [48] http://www.w3.org/2001/tag/issues.html#abstractComponentRefs-37
     [49] http://www.w3.org/2001/tag/doc/abstractComponentRefs-20031030
     [50] http://www.w3.org/2001/tag/open-summary.html#contentPresentation-26
     [51] http://www.w3.org/2001/tag/doc/contentPresentation-26-20030630.html
     [52] http://www.w3.org/2001/tag/open-summary.html#metadataInURI-31
     [53] http://www.w3.org/2001/tag/issues.html#siteData-36
     [54] http://www.tbray.org/ongoing/When/200x/2004/01/08/WebSite36

4. Other action items

     * Action PC/IJ: Proposed revised [55]TAG charter
     * Action RF 2003/10/08: Explain "identifies" in RFC 2396.
     * Action DC 2003/11/15: Follow up on KeepPOSTRecords with Janet Daly
       on how to raise awareness of this point (which is in CUAP).
     * Action CL 2003/10/27: Draft XML mime type thingy with Murata-san

     [55] http://www.w3.org/2001/07/19-tag


    Ian Jacobs for Stuart Williams and TimBL
    Last modified: $Date: 2004/03/23 22:54:08 $

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

Received on Tuesday, 23 March 2004 18:37:08 UTC

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