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

[Minutes] 19 Jan 2004 TAG teleconf (I18N issues)

From: Ian B. Jacobs <ij@w3.org>
Date: Mon, 19 Jan 2004 23:39:10 -0500
To: www-tag@w3.org
Cc: duerst@w3.org, ishida@w3.org, aphillips@webmethods.com, yergeau@alis.com
Message-Id: <1074573549.3390.170.camel@seabright>

Minutes of the TAG's 19 Jan 2004 teleconference are
available as HTML [1] and as text below.

 - Ian

[1] http://www.w3.org/2004/01/19-tag-summary.html
                 Minutes of 19 January 2004 TAG teleconference

1. Administrative (15min)

    1. Roll call. SW, TBL, DO, NW, PC, IJ, TB, RF. From I18N WG: Franois
       Yergeau, Martin Drst, Richard Ishida, Addison Phillips.
       Regrets: DC. Absent: CL.
    2. Resolved to accept minutes of the [9]12 Jan teleconf
    3. Accepted this [10]agenda
    4. Next meeting: 26 Jan 2004. I18N WG invited back at teleconf start
       time + 45 minutes.

      [9] http://www.w3.org/2004/01/12-tag-summary.html
     [10] http://www.w3.org/2004/01/19-tag.html

  1.1 Video meeting in Feb 2003

    1. Action SW/PC 2003/11/10: Explore possibility of TAG videolink TAG
       distributed meeting in February. ([11]Done)

     [11] http://lists.w3.org/Archives/Member/tag/2004Jan/0044.html

   Resolved: Per [12]proposal from SW, TAG will hold video meeting 9
   February 2004.

     [12] http://lists.w3.org/Archives/Member/tag/2004Jan/0044.html

  1.2 Technical Plenary

    1. Continued action SW 2003/11/15: Take to tech plenary committee the
       TAG's proposal.
    2. [13]TAG 2 Mar 2004 ftf meeting page

     [13] http://www.w3.org/2004/03/02-tag-mtg.html


          SW: COmmittee would like 30-min overview of arch doc. Hot topic
          issue ideas:
          - Mixed language
          - Linking in XML
          - HTTPRange-14
          SW: I have an action to ask the TAG to name 3-4 hot issues for
          tech plenary discussion. Mixed langauge resonated with folks
          from others in the planning committee.
          NW: +1 to linking in XML

          +1 to linking in XML

          DO: HTTPRange-14. I think having the debate would help
          technical folks see why we are where we are.: -1 to linking in
          XML. +1 to interpretation of fragids; abstract components.

          timbl, you wanted to wonder about the XML chunk
          canonicalization issue, and to exprss concern about

          TBL: I'm a bit worried about httpRange-14. Don't want to rehash
          for the purpose of rehashing.

  1.3 TAG meeting schedule in 2004

    1. Action PC 2004/01/05: Propose meeting schedule for next 4 (or so)
       TAG ftf meetings. Due: 12 Jan 2004.
       PC: Please continue.

2. Technical (75min)

   See also [14]open actions by owner and [15]open issues.

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

  2.1 Discussion with Internationalization WG representatives

     * [16]charmodReview-17
          + TAG finding related to adoption of Charmod? See [17]mail from
          + Schedule ftf time during tech plenary week.
          + [18]Charmod LC issues and [19]TAG comments. See also [20]CL

     [16] http://www.w3.org/2001/tag/issues.html#charmodReview-17
     [17] http://www.w3.org/mid/361483C6-96E6-11D7-9C47-000393914268@w3.org
     [18] http://www.w3.org/2002/06/charmod-lastcall2/
     [19] http://lists.w3.org/Archives/Public/www-i18n-comments/2002Jun/0000.html
     [20] http://lists.w3.org/Archives/Public/www-tag/2002May/0164.html


          (DO: Note that on issue 40: Schema WG has responded to proposed
          finding on abstract component identifiers; want to know what's
          wrong with using xpointer + brackets.)
          TAG welcomes guests.
          TBray: What's the general state of the world re: the Charmod
          apphillips: We've almost completed handling of LC comments on
          Charmod. We were asked to review early uniform normalization,
          and also asked to split document to push non-controversial
          pieces to Rec more quickly. We have a plan to complete work on
          character model by:
          1) Splitting the document in two:
          a) Things not related to normalization
          b) Normalization, string matching, indexing.
          2) Schedule is to advance part one to LC by end of February
          3) Create WD for part 2, with eye of getting to Rec in summer

          (re splitting: and there was much rejoicing!)

          apphillips: One comment we received re: charmod was that it
          makes a number of normative statements about the work of other
          groups. It is our understanding that the TAG would be a better
          group to make such statemetns for other groups.
          TBray: How are I18N Resources for advancing work?
          apphillips: We have resources to complete this work.
          TBray: I'm delighted you have agreed to splitting the document.
          [General enthusiasm about splitting]
          MD: I note that all of the "tough issues" are in part II.
          PC: Originally we had suggested splitting in three. Please
          explain your proposed split.
          apphillips: The document was not simply hacked in two. We could
          foresee a part III in the future.
          PC: Not sure what you meant re: normative requirements on other
          apphillips: "If you are going to write a W3C Recommendation,
          you MUST...."
          MD: W3M considered different proposals for ensuring how best to
          set policies without putting text in a Recommendation. W3M
          Recommended that the TAG issue a finding. Ideally we should
          start a draft finding now (or next time the charmod is
          published) and move the finding to approved state in step with
          the charmod spec.

          I'm not sure why it's better for the TAG to say that I18n says
          you should do this, as opposed to i18n group just saying you
          should do this

          TBL: It's a question of the role of a specification in the
          world. Technical specifications define a language or protocol.
          XML folks can describe what XML is. But the specs only define
          terms. The XML folks did not write a spec that said "All W3C
          specs SHALL BE in XML."
          TBL: Two reasons:
          a) Not their role. If a WG can lay down the law to other WGs,
          it makes it difficult for one WG to move on; creates more
          interdependencies. You end up defining a W3C process.
          b) There is peer pressure to use specs, not mandatory
          TBL: The TAG hasn't said "You MUST use XML."

          yep, 3470 is a BCP

          TBL: The TAG can say "This is why it's there; this is how it
          fits in; if you disagree, please come talk to us."

          perhaps the TAG ought to say "You SHOULD use CharMod"

          Another semi-exception is webarch

          MJDuerst, you wanted to say that in some way, the W3C is
          looking for the equivalent of BCP in IETF and to say that
          Charmod, same way as WebArch, is an architectural document

          MD: Like Webarch, Charmod is an architectural specification -
          doesn't define a language.
          PC: XML Base spec is an example of a spec that suggests that
          other specs use it.

          So webarch is a single point of entry for meta-ness so to speak

          PC: Early normalization requires a certain critical mass of
          software doing this in the market. Delicate timing problem.
          apphillips: That is the big concern we are actively

          If that's the case I'd *really* like to get a pointer to this
          thing into webarch 1.0

          PC: I am intrigued by a TAG finding that encourages software
          developers to move their software in a particular direction re:
          normalization. I am convinced that a TAG finding will help
          spread the word in my organizaiton.

          MJDuerst, you wanted to say if Charmod is split, there would be
          a TAG finding for each part.

          TBray: I'd like to have a pointer to Charmod in Webarch. I see
          that the Arch Doc could be used as a starting point for meta
          RI: Charmod not really like XML; if we get it right, it should
          be applicable almost all the time.
          TBL: Not sure charmod that different from XMl.
          TBray: Some parts will be compulsory (e.g., don't use ISO
          8859-1) while others will require judgment. Do you contemplate
          the draft distinguishing MUST from "PLEASE CONSIDER"
          apphillips: Much is written that way already.

          MJDuerst, you wanted to say that we have to add something in
          the Intro to say that you have to still think when you read

          MD: We need to make clear that this doc doesn't cover all I18N
          issues (e.g., formatting)
          Review of TAG issues brought to the I18N WG.


     [21] http://www.w3.org/International/Group/2002/charmod-lc/SortByGroup#C049

          C114: Specifications SHOULD NOT add rules for character
          encoding beyond what is provided in XML
          NW: Our particular concern was the XML case.
          TBray: XML has well-defined rules about char encoding
          requirements. We added a sentence: "When basing a protocol,
          format, or API on a protocol, format, or API that already has
          rules for character encoding, specifications SHOULD use rather
          than change these rules.
          EXAMPLE: An XML-based format should use the existing XML rules
          for choosing and determining the character encoding of external
          entities, rather than invent new ones. "
          NW: I think that satisfies the spirit of our comment.
          MD: Note that this says "SHOULD"
          TBray: Might be worthwhile to point to RFC3470
          [RI notes]
          Resolved: The TAG is satisfied with the disposition of this
          issue as suggested by I18N for C114.
          C115: <split>


          MD: We think this is editorial; have decided not to do this
          TBray: I hope there will be stable, addressable normative text.
          I want URIs to identify conformance requirements.
          MD: We'll take this back and look at it.

          MD, AP: Sounds reasonable.

          C116 Open
          C117: The use, within the spec, of images of characters
          MD: The claim is that we violate our own suggestions by using
          graphics for text. We have made some corrections.

          I think, based on a quick scan through all the TAG-labeled
          stuff, that we will be able to mark the vast majority of these

          MD: Our changes take into account the current state of deployed
          user agents.
          Resolved: TAG is happy with the WG's disposition re: comment


          C118: XML 1.0 and 1.1 are non conforming
          MD: Decision: Partially accepted.
          apphillips: Nothing that we've done breaks XML to our
          TBray: I'm satisfied.
          NW, PC: Satisfied.
          Resolved: TAG is happy with the WG's disposition re: comment
          C119: Split document in two.
          PROPOSED: TAG is [very] happy with the WG's disposition re:
          comment C119.
          RF: Note that it hasn't been split yet.
          TB, TBL, RF: Leave open until this is actually done.
          apphillips: We'll notify you when we have the WDs available.

          Note that I'm unhappy with the response to my C071; after a lot
          of thought the TAG wrote language that has been incorporated
          into RFC2396bis, it covers this point in depth: the phrase
          "bit-for-bit" is actively misleading. I'll post a follow-up to
          that as appropriate. Otherwise I'm 100% OK with all the other
          comments I raised

          SW: The TAG is happy with the direction of the I18N WG.
          C120: Remove parts dealing with collation and sorting
          MD: Decision: Partially accepted.We don't think we can just
          remove this: "In the context of Section 3.1, Perceptions of
          Characters, the fact that units of collation are different from
          other units, and the various issues, are important and well
          established. The text as well as the examples have been
          carefully chosen to show the range of phenomena. We do not see
          the need for a separate architectural document on collation and
          related issues; there are already an ISO standard and an
          Unicode Technical Standard, as well as many implementations,
          for user-oriented sorting/collation"
          RF: My impression upon reading this was that it would not be
          implemented. There aren't good examples of existing
          MD: There are performance issues, but this is implemented now:
          ICU (?). I also think Microsoft has implementations. We agree
          that servers should present results in the way the users want
          to see them.
          PC: Hard to find the Unicode algorithm.
          MD: Still separate as a Unicode technical report.


     [22] http://www.unicode.org/unicode/reports/tr10/

          TBL: Asking about status of test suites
          PC expressed frustration in other WGs at difficulty in finding
          the algorithm
          TBL: how do they know they've got it right?
          Addison: charmod doesn't explicitly point at Unicode Collation
          Algorithm currently
          MD: if you have another one that works better, you can use it,
          e.g. Microsoft currently uses others that they think works
          Addison: if we were to recommend UCA, we'd have to make sure
          that Unicode produces thoses or do it themselves...

          TBray: Lots of applications where you explicitly do want to
          sort using Unicode collation sequence.
          SW: I think this issue seems open still.
          MD: We would like a formal reply by RF (or CL) on this one.

          Re my issue C071: see

     [23] http://www.gbiv.com/protocols/uri/rev-2002/draft-fielding-uri-rfc2396bis-03.html#comparison-string

          MD: This would be for Part I.


     [24] http://www.w3.org/International/Group/charmod-edit/


     [25] http://www.w3.org/International/Group/charmod-edit/Overview.html#sec-CollationUnits

          TBray: What does "must" mean?
          apphillips: There is an intentional "lower case must"
          TBray: I don't see anything to object to.
          RF: My original objections were that all software use UTF-8 to
          begin with. I don't see that anymore. There used to be a
          requirement that all specs specify processing per the reference
          processing model...
          MD: That's still there, but in another section. C120 is not
          about that, however.

          I'm OK with 3.1.5 as written

          MD: I note also that this is only observable behavior. If you
          can get the same result another way, that's fine.
          PC: To close off on a previous point, cf para at bottom of
          3.1.5. I can't find the "default collation order" in the
          reference [To take offline]. The previous paragraphs have
          SHOULD statements; it's fair to state that one reason they
          can't be stronger than that is that, e.g., the database
          industry has made collation an artifact of the data as stored,
          not of the user's preferences.
          MD: I agree that there are strong performance issues there.
          PC: I think the Query WG supports these SHOULDS (and does
          SW: We can continue this face-to-face in Cannes.
          apphillips: Our goal is to have a WD ready by the tech plenary.
          We will have some new material by then.
          SW: If we use half of our time next week, are people
          TBray: Yes.
          MD: I think it would be productive for TB to review what we
          sent him.
          Action TB: Send back replies to I18N regarding their proposals
          for addressing TB's issues.
          Proposed for I18N WG to join 26 Jan TAG teleconf 45 minutes
          into call.

          Once again, thanks to the i18n guys for showing up!

          SW: Thanks all for attending.


   TR10: default collation table:


   The TAG does not intend to discuss topics below this line at this
     * [26]URIEquivalence-15
     * [27]IRIEverywhere-27

     [26] http://www.w3.org/2001/tag/issues.html?view=normal&closed=1#URIEquivalence-15
     [27] http://www.w3.org/2001/tag/issues.html#IRIEverwhere-27

  2.2 XML Canonicalization

     * Action TBL 2004/01/05: Propose a new issue regarding
       canonicalization to www-tag ([28]Done). PC to respond with
       pointers to relevant specifications ([29]Done).

     [28] http://lists.w3.org/Archives/Public/www-tag/2004Jan/0013.html
     [29] http://lists.w3.org/Archives/Public/www-tag/2004Jan/0015.html

3. Issues

   Issues that are open and that we expect to close by the end of last
     * [30]rdfmsQnameUriMapping-6
     * [31]whenToUseGet-7
     * [32]contentTypeOverride-24

     [30] http://www.w3.org/2001/tag/issues.html?view=normal&closed=1#rdfmsQnameUriMapping-6
     [31] http://www.w3.org/2001/tag/issues.html?view=normal&closed=1#whenToUseGet-7
     [32] http://www.w3.org/2001/tag/issues.html?view=normal&closed=1#contentTypeOverride-24

4. Status report on these findings

   See also [33]TAG findings
     * [34]qnameAsId-18
          + 6 Jan 2004 draft finding "[35]Using Qualified Names (QNames)
            as Identifiers in Content"
     * [36]contentTypeOverride-24:
          + 10 Dec 2003 draft finding "[37]Client handling of MIME
     * [38]abstractComponentRefs-37:
          + 30 Oct 2003 draft finding "[39]Abstract Component References"
     * [40]siteData-36
          + "[41]There is no such thing as a Web site"
     * [42]contentPresentation-26:
          + 30 June 2003 draft finding "[43]Separation of semantic and
            presentational markup, to the extent possible, is
            architecturally sound"
     * [44]metadataInURI-31
       SW: I hope to make progress before end of month.

     [33] http://www.w3.org/2001/tag/findings
     [34] http://www.w3.org/2001/tag/issues.html#qnameAsId-18
     [35] http://www.w3.org/2001/tag/doc/qnameids-2004-01-06
     [36] http://www.w3.org/2001/tag/open-summary.html#contentTypeOverride-24
     [37] http://www.w3.org/2001/tag/doc/mime-respect.html
     [38] http://www.w3.org/2001/tag/issues.html#abstractComponentRefs-37
     [39] http://www.w3.org/2001/tag/doc/abstractComponentRefs-20031030
     [40] http://www.w3.org/2001/tag/issues.html#siteData-36
     [41] http://www.tbray.org/ongoing/When/200x/2004/01/08/WebSite36
     [42] http://www.w3.org/2001/tag/open-summary.html#contentPresentation-26
     [43] http://www.w3.org/2001/tag/doc/contentPresentation-26-20030630.html
     [44] http://www.w3.org/2001/tag/open-summary.html#metadataInURI-31

5 Other action items

     * 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


    Ian Jacobs for Stuart Williams and TimBL
    Last modified: $Date: 2004/01/20 04:34:22 $

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

Received on Monday, 19 January 2004 23:39:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:03 UTC