- 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>
Hello,
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
[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 [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
TBL
+ Schedule ftf time during tech plenary week.
+ [18]Charmod LC issues and [19]TAG comments. See also [20]CL
comments.
[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
[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]
[21]http://www.w3.org/International/Group/2002/charmod-lc/SortB
yGroup#C049
[21] 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]
[22]http://www.unicode.org/unicode/reports/tr10/
[22] 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
[23]http://www.gbiv.com/protocols/uri/rev-2002/draft-fielding-u
ri-rfc2396bis-03.html#comparison-string
[23] 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]
[24]http://www.w3.org/International/Group/charmod-edit/
[24] http://www.w3.org/International/Group/charmod-edit/
[fyergeau]
[25]http://www.w3.org/International/Group/charmod-edit/Overview
.html#sec-CollationUnits
[25] 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.
* [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
call:
* [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
headers"
* [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