- From: Paul Cotton <pcotton@microsoft.com>
- Date: Tue, 8 Apr 2003 19:49:04 -0400
- To: "Ian B. Jacobs" <ij@w3.org>, <www-tag@w3.org>
>[Chris] >who wil be there - ian, paul, chris, timbl This may be what Chris said but I believe it is possible that other TAG members may also be at the conference. Paul Cotton, Microsoft Canada 17 Eleanor Drive, Nepean, Ontario K2E 6A3 Tel: (613) 225-5445 Fax: (425) 936-7329 mailto:pcotton@microsoft.com > -----Original Message----- > From: Ian B. Jacobs [mailto:ij@w3.org] > Sent: April 7, 2003 6:42 PM > To: www-tag@w3.org > Subject: [Minutes] 7 Apr 2003 TAG teleconf (arch doc, contentTypeOverride- > 24, namespaceDocument-8, IRIEverywhere-27) > > > Hello, > > The minutes of the 7 Apr 2003 TAG teleconf are > available as HTML [1] and as text below. > > - Ian > > [1] http://www.w3.org/2003/04/07-tag-summary.html > > ==================================================== > > Minutes of 7 Apr 2003 TAG teleconference > > Nearby: [4]IRC log | [5]Teleconference details * [6]issues list * > [7]www-tag archive > > [4] http://www.w3.org/2003/04/07-tagmem-irc.html > [5] http://www.w3.org/2001/tag/group/#remote > [6] http://www.w3.org/2001/tag/ilist > [7] http://lists.w3.org/Archives/Public/www-tag/ > > 1. Administrative > > 1. Roll call: NW (Chair), TBL, PC, DO, TB, CL, RF, IJ (Scribe): > Regrets: SW. Missing: DC. > 2. Accepted [8]31 Mar telecon minutes > 3. Accepted this [9]agenda > 4. Accepted [10]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. > > [8] http://www.w3.org/2003/03/31-tag-summary.html > [9] http://www.w3.org/2003/04/07-tag.html > [10] http://lists.w3.org/Archives/Member/tag/2003Apr/0007.html > > 1.1 Meeting planning > > * The TAG will strive to organize a virtual meeting shortly after > the WWW Conference. See [11]thoughts from SW on organizing a > virtual meeting. > Completed action TBL 2003/03/31: Propose June dates (after 4 > June). (See [12]questionnaire) > The TAG will try to finalize the date next week after remaining > TAG participants have completed questionnaire. > * Upcoming discussions: > + The TAG expects to discuss its presentation to the AC on 14 > and 21 April. > + Action IJ: Report to mtg organizer TBL constraint on slot for > TAG report, then report back to TAG on revised slot. > > [11] http://lists.w3.org/Archives/Member/tag/2003Mar/0082.html > [12] http://www.w3.org/2002/09/wbs/34270/05%252F06.03/ > > 1.2 W3C Track Presentation > > * [13]W3C track [30]: "TAG scope" > * [14]Notes from Paul Cotton > > [13] http://www2003.org/t_www.htm > [30] http://www.textuality.com/xml/rddl3.html > [14] http://lists.w3.org/Archives/Member/tag/2003Apr/0010.html > > [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. [15]Architecture document > 2. [16]contentTypeOverride-24 > 3. [17]namespaceDocument-8 > 4. [18]IRIEverywhere-27 > > 2.1 Architecture document > > See also: [19]findings. > 1. [20]26 Mar 2003 Working Draft of Arch Doc: > 1. Action DC 2003/02/06: Attempt a redrafting of 1st para under > [21]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. ([22]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 [23]message passing, a dual of > shared state. > > [19] http://www.w3.org/2001/tag/findings > [20] http://www.w3.org/TR/2003/WD-webarch-20030326/ > [21] http://www.w3.org/2001/tag/2002/webarch-20030206#uri-use > [22] http://lists.w3.org/Archives/Public/www-tag/2003Apr/0034.html > [23] http://lists.w3.org/Archives/Public/www-tag/2003Mar/0018.html > > [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 > > * [24]contentTypeOverride-24 > + See [25]email from DC to Voice Browser WG. > + Completed action IJ 2003/03/24: Draft up some language; make > connection to error-handling issue. TAG position with > rationale why to not override server value of content type. > ([26]Done) > > [24] http://www.w3.org/2001/tag/open- > summary.html#contentTypeOverride-24 > [25] http://lists.w3.org/Archives/Public/www-tag/2003Feb/0085.html > [26] http://www.w3.org/2001/tag/doc/mime-respect-20030405.html > > [Ian] > IJ: I completed the action item, but haven't made the [27]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 [28]Internet Media Type registration, consistency of > use > IJ: Yes, I agree. I'll put publication of this on agenda for > next week > > [27] http://www.w3.org/2001/tag/doc/mime-respect-20030405.html > [28] http://www.w3.org/2001/tag/2002/0129-mime > > 2.3 namespaceDocument-8 > > * [29]namespaceDocument-8 > + Next steps on [30]RDDL Proposal from [31]Tim Bray/Paul Cotton > > [29] http://www.w3.org/2001/tag/open-summary.html#namespaceDocument-8 > [30] http://www.textuality.com/xml/rddl3.html > [31] http://lists.w3.org/Archives/Public/www-tag/2003Feb/0213 > > [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 > [32]http://lists.w3.org/Archives/Member/tag/2003Apr/0012.html > for my view. > > [32] http://lists.w3.org/Archives/Member/tag/2003Apr/0012.html > > [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 [$1\47] 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 > [33]http://www.textuality.com/xml/rddl3.html > > [33] 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 > > * [34]IRIEverywhere-27 > + Action CL 2003/03/31: Revised position statement on use of > IRIs. See [35]email from CL on next steps. > > [34] http://www.w3.org/2001/tag/open-summary.html#IRIEverywhere-27 > [35] http://lists.w3.org/Archives/Public/www-tag/2003Apr/0033.html > > [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 > [36]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. > > [36] http://www.w3.org/International/iri-edit/ > > [TBray] > Kanji example in > [37]http://www.tbray.org/ongoing/When/200x/2003/03/31/IRI > > [37] 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 > > * [38]URIEquivalence-15 > + SW proposal: Track RFC2396bis where [39]Tim Bray text has > been integrated. Comment within the IETF process. Move this > issue to pending state? > * [40]xmlIDSemantics-32 > + See [41]Chris Lilley draft finding > * [42]abstractComponentRefs-37 > * [43]xlinkScope-23 > + Status report? > + See [44]draft, and [45]SW message to CG chairs. > * [46]siteData-36 > + Action TBL 2003/02/24 : Summarize siteData-36 > * [47]xmlFunctions-34 > + Action TBL 2003/02/06: State the issue with a reference to > XML Core work. See [48]email from TimBL capturing some of the > issues. > * [49]binaryXML-30 > + Action TB 2003/02/17: Write to www-tag with his thoughts on > adding to survey. > + Next steps to finding? See [50]summary from Chris. > * [51]contentPresentation-26 > + Action CL 2003/02/06: Create a draft finding in this space. > Deadline 3 March. > * [52]rdfmsQnameUriMapping-6 > + Action DC 2003/02/06: Propose TAG response to XML Schema > desideratum ([53]RQ-23). > * [54]uriMediaType-9 > + Action DC 2003/02/06: Start discussion on > discuss@apps.ietf.org, but not urgent > * [55]HTTPSubstrate-16 > + Action RF 2003/02/06: Write a response to IESG asking whether > the Web services example in the SOAP 1.2 primer is intended > to be excluded from RFC 3205 > + See [56]message from Larry Masinter w.r.t. Web services. > * [57]errorHandling-20 > + Action CL 2003/02/06: Write a draft finding on the topic of > (1) early/late detection of errors (2) late/early binding (3) > robustness (4) definition of errors (5) recovery once error > has been signaled. Deadline first week of March. > * [58]metadataInURI-31 > + Action SW 2003/02/06: Draft finding for this one. > * [59]fragmentInXML-28 : Use of fragment identifiers in XML. > 1. Connection to content negotiation? > 2. Connection to opacity of URIs? > 3. No actions associated / no owner. > > [38] http://www.w3.org/2001/tag/open-summary.html#URIEquivalence-15 > [39] http://www.textuality.com/tag/uri-comp-4 > [40] http://www.w3.org/2001/tag/ilist#xmlIDSemantics-32 > [41] http://www.w3.org/2001/tag/doc/xmlIDSemantics-32.html > [42] http://www.w3.org/2003/04/24-tag- > summary.html#abstractComponentRefs-37 > [43] http://www.w3.org/2001/tag/ilist.html#xlinkScope-23 > [44] http://lists.w3.org/Archives/Member/tag/2003Mar/0094.html > [45] http://lists.w3.org/Archives/Member/tag/2003Mar/0104 > [46] http://www.w3.org/2001/tag/ilist.html#siteData-36 > [47] http://www.w3.org/2001/tag/ilist#xmlFunctions-34 > [48] http://lists.w3.org/Archives/Public/www-tag/2003Feb/0309.html > [49] http://www.w3.org/2001/tag/open-summary.html#binaryXML-30 > [50] http://lists.w3.org/Archives/Public/www-tag/2003Feb/0224.html > [51] http://www.w3.org/2001/tag/open- > summary.html#contentPresentation-26 > [52] http://www.w3.org/2001/tag/open- > summary.html#rdfmsQnameUriMapping-6 > [53] http://www.w3.org/TR/2003/WD-xmlschema-11-req-20030121/#N400183 > [54] http://www.w3.org/2001/tag/open-summary.html#uriMediaType-9 > [55] http://www.w3.org/2001/tag/open-summary.html#HTTPSubstrate-16 > [56] http://lists.w3.org/Archives/Public/www-tag/2003Feb/0208.html > [57] http://www.w3.org/2001/tag/open-summary.html#errorHandling-20 > [58] http://www.w3.org/2001/tag/open-summary.html#metadataInURI-31 > [59] http://www.w3.org/2001/tag/ilist#fragmentInXML-28 > > 3. Other actions > > * Action IJ 2003/02/06: Modify issues list to show that > actions/pending are orthogonal to decisions. IJ is working with > PLH on this. Revisit this end of April. > > _________________________________________________________________ > > > Ian Jacobs for Norm Walsh and TimBL > Last modified: $Date: 2003/04/07 22:36:12 $ > > > -- > Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs > Tel: +1 718 260-9447
Received on Tuesday, 8 April 2003 19:49:40 UTC