W3C | TAG |
Previous: 12 Jan teleconf | Next:
Minutes of 19 January 2004 TAG teleconference
Nearby: IRC log | Teleconference details | issues list (handling
new issues)| www-tag
1. Administrative (15min)
- 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.
- Resolved to accept minutes of the 12 Jan teleconf
- Accepted this agenda
- Next meeting: 26 Jan 2004. I18N WG invited back at teleconf
start time + 45 minutes.
1.1 Video meeting in Feb 2003
- 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
- Continued action SW 2003/11/15: Take to tech plenary committee
the TAG's proposal.
- TAG 2 Mar
2004 ftf meeting page
- SW: COmmittee would like 30-min overview of arch doc. Hot topic
- - 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
- 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
2.1 Discussion with Internationalization WG
- (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
- 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
- [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,
- 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
- 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
- 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.
- 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
- 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
- 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
- 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
- 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:
- 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
- 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
- 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
- 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
- PC: Hard to find the Unicode algorithm.
- MD: Still separate as a Unicode technical report.
- TBL: Asking about status of test suites
- PC expressed frustration in other WGs at difficulty in finding
- TBL: how do they know they've got it right?
- Addison: charmod doesn't explicitly point at Unicode Collation
- 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
- Re my issue C071: see http://www.gbiv.com/protocols/uri/rev-2002/draft-fielding-uri-rfc2396bis-03.html#comparison-string
- MD: This would be for Part I.
- 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
- 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
- MD: I agree that there are strong performance issues
- 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
- 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
- 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
2.2 XML Canonicalization
- Action TBL 2004/01/05: Propose a new issue regarding
canonicalization to www-tag (
Done). PC to respond with pointers to relevant specifications
Issues that are open and that we expect to close by the end of
4. Status report on these findings
See also TAG findings
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
- Action CL 2003/10/27: Draft XML mime type thingy with
Ian Jacobs for Stuart Williams and TimBL
Last modified: $Date: 2004/01/20 14:32:42 $