W3C | TAG | Previous: 12 Jan teleconf | Next: 26 Jan

Minutes of 19 January 2004 TAG teleconference

Nearby: IRC log | Teleconference details | issues list (handling new issues)| www-tag archive

1. Administrative (15min)

  1. Roll call. SW, TBL, DO, NW, PC, IJ, TB, RF. From I18N WG: François Yergeau, Martin Dürst, Richard Ishida, Addison Phillips.

    Regrets: DC. Absent: CL.

  2. Resolved to accept minutes of the 12 Jan teleconf
  3. Accepted this agenda
  4. Next meeting: 26 Jan 2004. I18N WG invited back at teleconf start time + 45 minutes.

1.1 Video meeting in Feb 2003

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

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

1.2 Technical Plenary

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

[Ian]

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
[TBray]
+1 to linking in XML
[Ian]
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.
[Zakim]
timbl, you wanted to wonder about the XML chunk canonicalization issue, and to exprss concern about httpRange-14
[Ian]
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 open actions by owner and open issues.

2.1 Discussion with Internationalization WG representatives

[Ian]

(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 spec?
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 (approx).
3) Create WD for part 2, with eye of getting to Rec in summer 2004.
[DanCon]
(re splitting: and there was much rejoicing!)
[Ian]
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 groups...
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.
[TBray]
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
[Ian]
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 statements.
TBL: The TAG hasn't said "You MUST use XML."
[TBray]
yep, 3470 is a BCP
[Ian]
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."
[r12a]
perhaps the TAG ought to say "You SHOULD use CharMod"
[TBray]
Another semi-exception is webarch
[Zakim]
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
[Ian]
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.
[TBray]
So webarch is a single point of entry for meta-ness so to speak
[Ian]
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 considering.
[TBray]
If that's the case I'd *really* like to get a pointer to this thing into webarch 1.0
[Ian]
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.
[Zakim]
MJDuerst, you wanted to say if Charmod is split, there would be a TAG finding for each part.
[Ian]
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 information.
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.
[Zakim]
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 Charmod
[Ian]
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.
[MJDuerst]
http://www.w3.org/International/Group/2002/charmod-lc/SortByGroup#C049
[Ian]
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>

---

C116
MD: We think this is editorial; have decided not to do this currently.
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.
[TBray]
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 resolved
[Ian]
MD: Our changes take into account the current state of deployed user agents.
Resolved: TAG is happy with the WG's disposition re: comment C117.

----

C118: XML 1.0 and 1.1 are non conforming
MD: Decision: Partially accepted.
apphillips: Nothing that we've done breaks XML to our awareness.
TBray: I'm satisfied.
NW, PC: Satisfied.
Resolved: TAG is happy with the WG's disposition re: comment C118.
----
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.
[TBray]
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
[Ian]
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 implementations.
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.
[Stuart]
http://www.unicode.org/unicode/reports/tr10/
[TBray]
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 better
Addison: if we were to recommend UCA, we'd have to make sure that Unicode produces thoses or do it themselves...
[Ian]
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.
[TBray]
Re my issue C071: see http://www.gbiv.com/protocols/uri/rev-2002/draft-fielding-uri-rfc2396bis-03.html#comparison-string
[Ian]
MD: This would be for Part I.
[r12a]
http://www.w3.org/International/Group/charmod-edit/
[fyergeau]
http://www.w3.org/International/Group/charmod-edit/Overview.html#sec-CollationUnits
[Ian]
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.
[TBray]
I'm OK with 3.1.5 as written
[Ian]
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 more).
----
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 interested?
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.
[TBray]
Once again, thanks to the i18n guys for showing up!
[Ian]
SW: Thanks all for attending.
[apphillips]

TR10: default collation table: http://www.unicode.org/reports/tr10/#AllKeys

The TAG does not intend to discuss topics below this line at this meeting.

2.2 XML Canonicalization

3. Issues

Issues that are open and that we expect to close by the end of last call:

4. Status report on these findings

See also TAG findings

5 Other action items

Ian Jacobs for Stuart Williams and TimBL
Last modified: $Date: 2004/01/20 14:32:42 $