W3C | TAG | Previous: 31 Mar teleconference | Next: 14 April 2003 teleconf

Minutes of 7 Apr 2003 TAG teleconference

Nearby: IRC log | Teleconference details · issues list · www-tag archive

1. Administrative

  1. Roll call: NW (Chair), TBL, PC, DO, TB, CL, RF, IJ (Scribe): Regrets: SW. Missing: DC.
  2. Accepted 31 Mar telecon minutes
  3. Accepted this agenda
  4. Accepted summary of TAG activity with two suggestions:
    1. PC reminder about report to AC in May
    2. CL suggested wording for progress on issues
    3. Action IJ: Send out summary with these changes.
  5. Next meeting: 14 April. No regrets signaled.

1.1 Meeting planning

1.2 W3C Track Presentation

[Chris]
'what is the tag and why should you care" fits in 30 minutes
[Chris]
when is the www slot, actually?
[Ian]
PC suggestion:
  1. scope and role of the TAG
  2. sample findings issued by the TAG and their results
  3. overview of the Web Architecture document
[Chris]
who wil be there - ian, paul, chris, timbl
[Ian]
NW: Please reply on email to PC's proposal
Next week: TAG will finalize who will give which piece of the track presentation on 14 April.

2. Technical

  1. Architecture document
  2. contentTypeOverride-24
  3. namespaceDocument-8
  4. IRIEverywhere-27

2.1 Architecture document

See also: findings.

  1. 26 Mar 2003 Working Draft of Arch Doc:
    1. Action DC 2003/02/06: Attempt a redrafting of 1st para under 2.2.4 of 6 Feb 2003 draft
    2. Action DC 2003/01/27: write two pages on correct and incorrect application of REST to an actual web page design
    3. Action DO 2003/01/27: Please send writings regarding Web services to tag@w3.org. DO grants DC license to cut and paste and put into DC writing.
    4. Completed action CL 2003/0127: Draft language for arch doc that takes language from internet media type registration, propose for arch doc, include sentiment of TB's second sentence from CP10. (Done)

      CL: Belongs in section 4.2 of Architecture Document.

    5. Action DC 2003/03/17: : Write some text for interactions chapter of arch doc related to message passing, a dual of shared state.

[Ian]

Done.
IJ: Who is reading the arch doc?
[Ian]
NW: I am getting closer to reading it.
[Chris]
I have been reading it this week, yes
[Ian]
TBL also reading arch doc.

2.2 contentTypeOverride-24

[Ian]
IJ: I completed the action item, but haven't made the draft public. I intend to publish this in a week; please review.
CL: Some of the material was in an earlier finding. Please link back to Internet Media Type registration, consistency of use
IJ: Yes, I agree. I'll put publication of this on agenda for next week

2.3 namespaceDocument-8

[Ian]

TB: I have an action to fix this up to ensure that it's valid, modularized xhtml. Two substantive issues before the TAG:
  1. Do we support this version of RDDL on a technical basis?
  2. How do we move it forward?
TBL: I think that the TAG is not set up to be a WG at this time; Rec track docs would be quite a drain on resources at this time. If this were a draft, I think at this time it would be better to fork off another WG.
[paulc]
Please see http://lists.w3.org/Archives/Member/tag/2003Apr/0012.html for my view.
[Ian]
TBL: Another possibility is to say "we don't think this is contentious, we don't have time to get review, we'll publish as a Note.": Then, if picked up, then can put on Rec track. Or if not used because of problems, move to a WG for more work.
PC: On this front, I think the TAG should "ask permission" and not "ask forgiveness". Therefore I would like to propose the following:
  1. we publish our proposal for namespacedocument-8 [2] as a Note ASAP
  2. we specifically request input for the AC membership at the May AC on how the content of this Note if and should be progressed to Recommendation track.
PC: We should negotiate this precedent with the AC. With simple change by TB, we could publish as Note quickly and get ac feedback.
TB: I think I agree with TBL and PC; don't want to be sloppy to respond formally to public input. What about publishing this as a finding? I could also see publishing as a Note.
[Zakim]
Chris, you wanted to talk about life after rec, testsuites, and other resource suckers
[Ian]
CL: Lots of responsibilities for Rec track work (e.g., test suites, life after Rec, etc.) I support publication as a finding.
NW: I agree with PC (publication as a Note)
[Chris]
we could still ask the AC if the finding should go on the rec track and if so who should do it would work
[Ian]
NW: I think that findings have more stature; people used to seeing docs from TAG at this point. People are more used to seeing spec-like things as Notes.
IJ: Note more spec-like; TR page as location for document likely to get more attention.: I lean slightly towards Note publicatoin.
[Zakim]
timbl_, you wanted to ask about links from http://www.textuality.com/xml/rddl3.html
[Ian]
Action TB: (1) Clean up messy section 4 of RDDL draft and (2) Investigate and publish a canonical mapping to RDF.
Summarizing: TAG doesn't think that Rec track best option for now (at least without consulting the AC).
TBL: I think finding is inappropriate; people expect a certain genre of thing in a finding. This is Note-like. We could publish a finding explaining why the Note is good....
TB: Can you have a Note that says "This represents the consensus of...."
IJ: Yes.
[TBray]
What Norm said
[Chris]
finding can be short, but should still exist
[Ian]
Proposed: Plan is to publish TB's revised RDDL document as a W3C Note. Status section would say that it represents the consensus of the TAG.
CL: The finding would say why the solution is desirable.
IJ: I think that rationale would be better in the document.
[paulc]
Where do we say that users of namespaces SHOULD use the suggested format.
[Ian]
CL: I'd like each issue to close with a finding.
[Chris]
its a consistency thing
[Ian]
TB: Current language in Note does not say "namespaces SHOULD use the suggested format." I would be fine to say that, but don't think it needs it.
[TBray]
Current doc says "A Resource Directory is designed to be suitable for service as the body of an entity returned by dereferencing a URI serving as an XML Namespace name."
[Ian]
TBL: I hear PC saying put language spec in a Note, put recommendations on usage in a finding. I feel that we can put the RDDL Note forward, but I agree where there will be applications where people will use XML or RDF schema. I don't want to force people to use it.
NW: I agree with CL to use finding to answer finding, publish spec in Note.
[TBray]
OK, I can go with the the 2-doc solution
[Ian]
IJ: I can go with the 2-doc solution.
Proposal: TAG expects to publish RDDL Spec as a Note (status section to indicate consensus of TAG), and to produce a finding to answer question of namespaceDocument-8, namely that groups SHOULD use RDDL.
TBL: I think we should say that RDDL is a good example (don't say "SHOULD" in finding; just indicate RDDL as a good example).
[DaveO]
I think we should say that RDDL should be used.
[Ian]
Proposal: TAG expects to publish RDDL Spec as a Note (status section to indicate consensus of TAG), and to produce a finding to answer question of namespaceDocument-8.
[timbl_]
ok by me
[Ian]
TB: I'm optimistic that in the finding we'll find consensus on verbiage.
[timbl_]
I don't want to recommend RDDL any more than we recommend XML, RDF or SVG
[Ian]
Proposal: TAG expects to publish RDDL Spec as a Note (status section to indicate consensus of TAG that this is a suitable representation of a resource), and to produce a finding to answer question of namespaceDocument-8 (with some sort of pointer to the RDDL spec).
Proposal: TAG expects to publish RDDL Spec as a Note (status section to indicate consensus of TAG that RDDL is a suitable format for representations of an XML namespace), and to produce a finding to answer question of namespaceDocument-8 (with some sort of pointer to the RDDL spec).
Resolved: TAG expects to publish RDDL Spec as a Note (status section to indicate consensus of TAG that RDDL is a suitable format for representations of an XML namespace), and to produce a finding to answer question of namespaceDocument-8 (with some sort of pointer to the RDDL spec).
Action TB: Work on RDDL Note.
Action PC: Work on TAG finding.

2.4 IRIEverywhere-27

[DaveO]
I have to step away for a few minutes.
[Ian]
CL: I'd like more discussion this week; deadline 21 April? Also need to convey to Martin the desirability of seeing http://www.w3.org/International/iri-edit/ updated to include iDNS and published as draft 4, and to move to RFC soon. I'd like to address question of 'blessed wording' regarding IRI that three XML-related specs can use to get to Proposed Rec.
[TBray]
Kanji example in http://www.tbray.org/ongoing/When/200x/2003/03/31/IRI
[Ian]
TBL: I think there is a fundamental question that has not been resolved, and is causing a lot of tension.: Whether, fundamentally, the fundamental string is the URI, or whether we are dispensing with URIs in favor of Unicode strings instead.
[Chris]
position A says IRI is a way of talking about URI
position B says IRI is the real thing and URI is a subset that should go away
[Ian]
TBL: I was under the impression during development of IRIs, that the model was position A. I think the TAG needs to adress this bifurcation (A v. B)
TB: I agree with the TBL and CL characterization of the heart of the issue.
[Chris]
and please lets get to blessed text after we have discussed this
[Ian]
TB: "Is any URI an IRI?" I think the answer is No; lots of sloppiness about hexifying.
[Chris]
strongly disagree with TimBray
[Ian]
TB: I think IRIs need to be rigid and deterministic about when hexifying is used, and that the mapping (to URI) process be well-characterized.
CL: I don't think it's true that all URIs are IRIs.

[Some discussion of equivalence measures around hexifying]

CL: It does not follow that the URI version of an IRI is the same as that IRI. It does not follow that the URI version of an IRI is the same as that IRI in all cases: same when you dereference; not the same in e.g., namespace comparisons.
NW: Why inappropriate to convert to URI before comparison?
CL: A number of specs don't do it that way; they do simple string matching in a number of specs. Therefore, not reasonable in practice to require conversion to URI. E.g., you have to have a kanji character and upper case hex and lower case hex to be the same.
[TBray]
We really need to do this in a room with a whiteboard
[Ian]
CL: Too much water to push uphill (especially when extra processing doesn't get you much).
[Zakim]
timbl_, you wanted to argue that theis is relatively little water to push up hill
[Ian]
TBL: I've been there too.... I was convinced of CL's argument, but upon further reflection believe it's untenable.: Suppose that identifiers are unicode strings and you don't have to canonicalize them to compare them. There is ten years of software using 7-bit fields for this quantity.
[paulc]
I need to step out for 3-4 min.
[Ian]
TBL: If suddenly you allow namespaces that can differ in 7-bit systems but not in 8-bit systems. Changing the XML spec is relatively easy. You have a transition strategy: ask them to canonicalize namespace IDs and xpaths. During the interim, the only time things actually fail is when people use things that only differ in case of hex encoding. So this is a corner case. Easier to move to full canonicalization and full equality and to be consistent with 10 years of code and fix latest departures.
CL: I strongly disagree.
TB: I'm not sure that CL and I disagree that much. In terms of URIs, it's a fact that everyone uses string comp in namespace applications. We have ample evidence that this is prone and shakey to failure, but people do it anyway.
[Chris]
everyone uses string comparison in namespace comparisons, and in xpath. and in xml query. and ....
[Ian]
TB: One reason has to do with hex-encoding. We can remove that sloppiness in the IRI spec; but we'd have to abandon the insistence that every URI is an IRI.
TBL: I hear TB proposing that IRIs are always canonical.
[Zakim]
Chris, you wanted to point out that I really, really want to talk about blessed text in the next 20 minutes
[paulc]
I'm back.
[Ian]
TBL: Are you saying, CL, that browsers that use hex encoding are wrong?
CL: Yes, they are doing it too early. They should do when they send over HTTP transport.
TBL: If you are telling me that the encoded and unencoded forms are equivalent....
CL: Yes.
RF: When a robot takes advantage of some heuristic, this is not for the purpose of determining equivalence of the identifier; it's equivalence of an operation.
TBL: Each algorithm in the deployed software, though, is using a different piece of the URI spec for its heuristics.
RF: There is a reason to create an equivalence relationship between IRIs and URIs. That there are other mechanisms that don't respect that equivalence is irrelevant. I agree with TBL.
NW: I think that TB is right - the key to make this all fit together is to say "Not all URIs are IRIs, and you define mappings that are reversible"
[Chris]
deprecated subset of URIs
[Ian]
[On text about IRIs in specs at this point]
CL: Should we be in the business of producing parts of specs that have guarantees associated with them, or not.: Or do we say "Here's our best guess, do the best you can to prepare something for the Director."
[Zakim]
timbl_, you wanted to say we should respond and we should not suggest the result has papal infallibility.
[Ian]
TBL: If we are talking about this, we owe people a response, but without any guarantees.
[Chris]
agree about the papal infallibility
[Ian]
TB: see language in xml 1.1...hmmm, doesn't say much.
CL: There is language in schema spec as well. People could point to that (It's a Rec)
TB: I think the anyURI type is underspecified. Last time I looked, there were very few syntactic restrictions on what you can put in an anyURI. I don't think that that's a good solution.
TBL: How about if we tell people to refer to the IRI draft. Then we explain to people what that means: When you refer to the IRI spec, you take on that %7e and %7E are the same.
[Chris]
this is the option A, push water uphill argument
[Ian]
TBL: That gets the XML specs off the hook. We need to explain that, the syntax and semantics are defined by URI specs.
NW: Core WG wants to say that these things are IRIs, not URIs.
[Chris]
Core WG wants to say these things are IRIs
[Ian]
TB: I think that it's clear that we probably can't solve their problem for them.: IRI, though the right answer, isn't done.
TBL: Propose that specs continue to be well-defined in terms of URIs, and only as well-defined as the IRI spec currently is. URI conformance + xml namespace conformance will give you this flexibility.
NW: A lot of existing software will no longer be conformant.
CL: XML Namespace software will break.
RF: But IRIs won't look in the future like they look today. IRIs will change to support IDNA.
NW: If you do what TBL just said, then you have to use URI comparison and not string comparison.
RF: Then use the field, define in the other specs as CDATA, and forget about it.
[Ian]
CL: I have an action to write this up.
[Chris]
I cannot complete writing this up
all proposed solutions have vehement objections
[Ian]
NW: IJ: please move the question of text that WGs may include in specifications up on the agenda next week.

No resolution.

2.5 Other issues that have associated action items

3. Other actions

Ian Jacobs for Norm Walsh and TimBL
Last modified: $Date: 2003/12/17 18:58:25 $