W3C | TAG | Previous: 15 Mar teleconference | Next: 29 Mar

Minutes of 22 March 2004 TAG teleconference

Nearby: Teleconference details · issues list (handling new issues)· www-tag archive

1. Administrative (20min)

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

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 open actions by owner and open issues.

2.1 Publication of Qname finding?

2.2 Internationalization Issues (charmodReview-17)

See 25 Feb 2004 WD of Charmod Fundamentals

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

[Chris]
Three pieces of information (links are Member-only)
  1. Review of Charmod
  2. Review of Charmod part 2
  3. On IRIs
[Ian]
CL: Exec summary is: except where noted we are satisfied. I'd like to discuss some minor issues during this call.
[Chris]

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.
[Ian]
Is "selection" defined?
[DanC]
How does this relate to web architecture?
[Ian]
CL: I made this comment before. They improved the text. But this one conformance requirement has the same wording. Yes, selection is defined.
[Chris]
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.

[Ian]
CL: I haven't suggested alternative wording; just expressed a concern.
TBL: I suggest you propose wording for them to include.
[Chris]
timbl says to send them wording
[Ian]
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?
[DanC]
I abstain; I'm happy for Chris to send these comments, but I have trouble relating them to our webarch work.
[Ian]
Resolved: TAG supports CL's statements (DC abstaining).

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

[DanC]
See my email: IRI section needs too much testing to go in Fundamentals.
[Ian]
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 follows..."
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 accurate.
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?

[DanC]
(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 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.
[Chris]
agreed
[Ian]
RF: People should use URIs since there is an operable spec; there isn't for IRIs.
[Chris]
sure there is; several W3C recs have them
[Ian]
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
[Ian]
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.
[DanC]
I'm willing to argue the point, but I don't insist on using the meeting time that way.
[Ian]
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 Process]
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.
[DanC]
does anybody know whether they're going to CR or PR next? I'd like the fundamentals less IRIs to go to PR.
[Ian]
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 beginnings of tests.
[Ian]
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.
[Chris]
I am willing to keep arguing.
[Ian]
Straw Poll: Who supports removing IRIs and moving forward? TBL, DC, PC, RF, SW, NW, MJ. Does not support: CL.
[Ian]
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).
[Chris]
IRI deals *exactly* with 'converting characters to bytes'.
[Ian]
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.
[Chris]
I have been putting tests together over the weekend, in fact.
[Ian]
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.
[Chris]
http://www.circleid.com/article/436_0_1_0_C/
[paulc]
+1 to CL's assessment of risk.
[Ian]
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."
[Roy]
The solution to technical uncertainty is not political certainty
[paulc]
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.
[Ian]
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).
[Ian]
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. (2) 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.
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.
[Chris]
I understand and support the 'breeze through' part
[Zakim]
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.
[Chris]
But there are 350,000 test cases already, in one month
[Ian]
TBL: I think there will be snags. We should encourage people to make tests and pursue this rapidly.
[Zakim]
Chris, you wanted to talk about what charmod actually says about IRI
[Ian]
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.
[Ian]
TBL: Do you have test suites and implementation experience for normalization form C?
[DanC]
I've seen sufficient tests for normal form C
[Chris]
OK I withdraw my No vote and agree with the majority so we now have consensus.
[Ian]
TBL: I haven't heard anything that suggests that an implementation report and an interop report wouldn't be fairly convincing.
[paulc]
Good job, Chris. Good effort making sure you understood the other side of the argument.
[Chris]
thanks, Paul
[timbl]
thanks, chris
[DanC]
IRI section needs too much testing to go in Fundamentals http://lists.w3.org/Archives/Public/www-i18n-comments/2004Mar/0012.html
[Ian]
Resolved: TAG supports LC comments from Dan Connolly.
No objections or abstentions.

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

Resources:

  1. Last Call issues list (sorted by section)
  2. Annotated version of WebArch
  3. Archive of public-webarch-comments
  4. 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).

Actions 2004/03/15 (due 25 March?) to review sections:

[Ian]

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 you.
[timbl]
Thanks, Roy.
[Ian]
SW: How to make progress on LC comments?
CL: Now that I'm done with IRI stuff, I can make progress this week.

2.3.1 Review of section 4.5.7

The tag reviewed an annotated version of the Arch Doc

Issue klyne26: Transcoding allowing by some or all intermediaries?

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.

[Chris]
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.
[Ian]
CL: +1 to Graham's comment.
CL: I think the mime spec talks about text/* in general.
[Chris]
We need to add a reference to the text/* media type description
[Ian]
DC: I propose to move on since CL has already committed to commenting this section.

2.3.2 Review of section 4.5.6

Issue kopecky6

TBL: Icon for "bug in the architecture"? Propose that this is editorial - see tag issue 32, which alas is still open.
DC: Seconded.
[Chris]
so we need to clarify that this is an open issue, not solved yet
[Ian]
DC: I look forward to a proposal from IJ regarding issue schema20.
IJ: I can propose text to make their example more explicit in the arch doc.
[Roy]
I suggest adding one paragraph (conclusion) from the finding, rather than just the reference.
[Chris]
http://www.w3.org/TR/2003/REC-xptr-framework-20030325/#shorthand
[Ian]
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

Issue kopecky5

DC: I am willing to reply to the reviewer and ask for clarification.
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

Issue booth3: NS document as definitive source of info on namespace

[Ian]
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"
[Ian]
TBL: We have used the term "authoritative".
[DanC]
I'm OK to demote booth3 to editorial
[Chris]
special case of authoritative metadata
[Ian]
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

Issue 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."
[Chris]
its false *because* ....??
[Ian]
RF: You can just say "globally unique names"
DC: right "in any context" adds nothing. Saying "can be understood" is a red flag.
[DanC]
I concur. s/ that can be understood in any context//
[Chris]
I agree that 'understood' is a whole other issue and unjustified here
[Ian]
TBL: XMLNS provides a mechanism for associating a tag with a pair of a URI and a local name.
[Chris]
a tag?
s/tag/element or attribute name/
[Ian]
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 question from DJW

1.1 Review of open action items related to issues

The TAG expects to review the list of 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.

3. Status report on these findings

See also TAG findings

4. Other action items

Ian Jacobs for Stuart Williams and TimBL
Last modified: $Date: 2006/08/18 10:15:16 $