19:48:35 RRSAgent has joined #tagmem 19:48:54 Zakim, pointer? 19:48:55 I don't understand your question, Chris. 19:49:03 rrsagent, pointer? 19:49:03 See http://www.w3.org/2003/01/06-tagmem-irc#T19-49-03 19:49:41 mutter mutter 19:49:58 DanC has changed the topic to: http://www.w3.org/2001/tag/2003/01/06-tag 19:54:35 crud; I haven't reviewed the 2nd draft on comparing URIs. 19:54:45 Stuart has joined #tagmem 19:55:24 Ian has joined #tagmem 19:58:47 zakim, what's the passcode? 19:58:48 sorry, Norm, I don't know what conference this is 19:58:58 zakim, this is tag 19:58:59 ok, Norm 19:59:03 +??P3 19:59:04 zakim, who's here? 19:59:05 On the phone I see Chris, Norm_Walsh, ??P3 19:59:05 On IRC I see Ian, Stuart, RRSAgent, Zakim, DanC, Chris, Norm 19:59:12 zakim, norm_walsh is Norm 19:59:14 +Norm; got it 19:59:22 zakim, ??P3 is me 19:59:23 +Stuart; got it 19:59:51 +DOrchard 20:00:00 +??P5 20:00:25 timMIT has joined #tagmem 20:00:50 zakim, ??P5 is Roy 20:00:51 Roy has joined #tagmem 20:00:51 +Roy; got it 20:00:57 +TimBL 20:01:14 Happy new Year everyone 20:01:30 Likewise to all 20:02:20 zakim, what's the code? 20:02:21 the conference code is 0824, Ian 20:02:26 +Ian 20:02:32 RRSAgent, start 20:02:48 +??P8 20:03:06 Zakim, ??P8 is Paul 20:03:07 +Paul; got it 20:03:07 zakim, ??P8 is PaulC 20:03:09 sorry, Norm, I do not recognize a party named '??P8' 20:03:17 Beat me to it :-) 20:03:26 Bonne Année à tous 20:03:45 pointer to 16Dec minutes is goofy; goes to a record of 9Dec 20:04:06 http://www.w3.org/2002/12/16-tag-summary 20:04:10 +DanC 20:04:12 DAn, mea culpa 20:04:38 PaulC has joined #tagmem 20:05:18 zakim, Paul is PaulC 20:05:19 +PaulC; got it 20:05:29 ???? ?????? SVG 1.0 ? W3C Recommendation????????? 20:06:24 RRSAgent, pointer? 20:06:25 See http://www.w3.org/2003/01/06-tagmem-irc#T20-06-24 20:06:41 zakim, who's here? 20:06:42 On the phone I see Chris, Norm, Stuart, DOrchard, Roy, TimBL, Ian, PaulC, DanC 20:06:43 On IRC I see PaulC, Roy, timMIT, Ian, Stuart, RRSAgent, Zakim, DanC, Chris, Norm 20:06:57 Roll call: All but TB. 20:07:06 Acceped 16 Dec minutes: http://www.w3.org/2002/12/16-tag-summary 20:07:14 http://www.w3.org/2002/12/16-tag-summary $Date: 2003/01/06 21:34:52 $ ok by me 20:07:51 +Tim_Bray 20:09:19 Next meeting: 13 Jan. 20:09:23 (No regrets) 20:09:30 -------- 20:10:01 I think I would like to get re-elected. 20:11:47 TBray has joined #tagmem 20:11:48 q+ 20:12:17 Paul's question: Do we have a formal status for "back burner issues"? 20:12:19 On mixedNamespaceMeaning-13: some vague discussion about putting on the back burner. 20:12:22 q+ 20:12:30 To Paul: Yes - "deferred" 20:12:35 q- 20:12:44 to say "I promise to rev Deeplinking-25 by end of January" 20:12:51 DC: I am still concerned about getting something done about some of these issues (deployment). 20:13:21 I think the TAG needs to think about how to evangelize its "architectural principles". 20:13:32 CL: Rec label will make a bigger splash. 20:14:06 ack DanC 20:14:08 DanC, you wanted to talk about deployment/impact 20:14:11 Evangelize: speaking in public, writing articles for the W3C web site, writing articles for publication in trade press, etc. 20:14:38 ack TBray 20:14:47 TB: I promise to do deepLinking-25 by the end of the month! 20:15:07 TB: I think we really ought to say that we are going to take the Arch Doc to last call, say, by 1 July. 20:15:17 CL: That sounds reasonable to me. 20:15:33 +1 on July 1 delivery for a first Last Call version of the Architecture document. 20:15:49 TBL: I find there's a fundamental problem with the doc without httpRange-14 resolved. 20:16:09 TBL: It's based on sand since I can't write axioms since terms not well-defined. 20:16:28 q? 20:16:36 TBL: Sandro Hawke has started working on text and came to the conclusion that the doc is difficult to work with with the doc in its current form. 20:16:39 q+ 20:18:01 PC: We need to evangelize the parts we already agree to (e.g., interviews, speaking opportunities). 20:18:20 q? 20:18:25 CL: I agree that we shouldn't hold up low-hanging fruit for thornier issues. 20:19:00 DC: I would be interested to find out more about the food chain of information going to webmasters, and get in the loop. 20:19:23 TB: I want to register my disagreement with TBL on the state of the arch doc; I think it is useful. 20:19:44 TB: I am willing to invest some more effort in httpRange-14, but we are chartered to produce a Rec. 20:20:23 RF: I find the document hard to work with as well. It's a compromise between two positions that doesn't satisfy either. 20:20:36 RF: I think finding the way to describe the terminology in a precise way is the way forward. 20:20:56 RF: We need to define the terminology associated with resources in a precise and consistent manner. 20:21:16 RF: I think httpRange-14 is a red herring. 20:21:25 ack TBray 20:22:20 TBL: httpRange-14 is about whether network-available resources are a distinct class. There is confusion between "things in general" and "Things with information content", which makes it difficult. 20:22:42 RF: I think it's necessary for us to agree to a set of terms, otherwise the doc's kind of pointless. 20:22:57 CL: I disagree. Some portions are independent. 20:23:11 RF: But we need to be able to say what is the target of a GET. 20:23:17 CL: Why can't the HTTP spec say that? 20:24:44 [Agreement that glossary with well-defined terms is important.] 20:24:47 q+ 20:25:33 q+ 20:25:44 What are the top 5 terms in the Architecture document that TimBL and Roy think need tighter definitions? 20:25:55 q? 20:25:59 q+ 20:26:06 q- 20:26:10 TBray has joined #tagmem 20:27:36 IJ: I think ongoing input from all participants will be key to getting to last call mid-year. 20:28:12 ack PaulC 20:28:15 q? 20:28:34 ack Roy 20:28:42 RF: I think discussion of last call should wait until Feb meeting. 20:29:02 RF: I think we need to write down different perspectives on what the terminology should be. 20:29:18 RF: I think that TimBL and my positions will likely converge once written down. 20:29:33 RF: Until then, it's in our court to suggest changes; TAG should not stop work while we do this. 20:30:34 AFK & phone for 3 minutes, sorry 20:30:36 RF: Terms come from 5-6 sources; we should not invent new terms. 20:30:53 RF: There's also descriptive text needed to explain what we're talking about. 20:31:09 Top 5: Resource, Information Resource (aka Document), URI, ... 20:31:34 q+ to point out that definitions from various specs are inconsistent 20:32:32 q- 20:32:50 RF: Nobody has sent me any text for RFC on URIs. 20:32:52 back 20:33:18 ----------------------------------- 20:33:21 Agenda items for ftf meeting. 20:33:25 - Arch Doc 20:34:29 DC: What specifically? 20:35:26 Norm has joined #tagmem 20:35:37 Norm has joined #tagmem 20:35:39 SW: httpRange-14 on back-burner or more attention? 20:35:49 TB: We have new input from Sandro Hawke. 20:36:45 TB: Sandro has also proposed some good language. 20:37:10 where did that edit go? 20:37:13 when did timbl do that? 20:37:45 there's a real issue here: whether the architecture recognizes two classes of URIs 20:37:47 TBL: I had produced a draft with language I thought was consistent. That text has been dropped. 20:38:15 q+ 20:38:25 q+ 20:38:26 TBL: Text that distinguishes documents (network available info) from other objects. 20:38:40 TBL: Those who work with Sem Web technology see this as a problem. 20:38:53 empirically there *are* two classes in practical usage 20:39:07 TBL: It's a problem when you try to build systems that model real-world objects. 20:39:09 but I see no gain & some loss in trying to write the difference into the architecture 20:39:29 TBL: RF has said that this is RDF's problem; I feel uncomfortable taking the group there again. 20:39:50 q+ 20:39:57 TBL: Sandro has a different solution: Identifiers always refer to documents. You must distinguish the case when you are referring to an abstract thing behind a document. 20:40:06 TBL: This is the only other consistent model I've seen. 20:40:25 CL: I heard TBL say we have lots of experience with URIs for documents/data. 20:40:38 CL: I agree, and I also agree that the sem web wants to point to things not on the Web. 20:41:06 CL: I agree with Sandro that the way to do that is to define a new way for doing so. One solution is a new URI scheme (e.g., "now" - not on the Web) 20:41:25 CL: This would indicate that the URI is not dereferenceable. 20:41:51 CL: I think we need a new mechanism to do new things, and leave the old one for old things, for which it works fine. 20:42:23 Stuart, pls phrase the question as "is there sufficient new information to believe that re-opening this issue for discussion would be worthwhile?" 20:42:25 And most importantly that would leave the *existing* way of pointing at network stuff alone 20:42:38 TB: Sandro has convinced me that I disagree with what CL said - defining a URI scheme for things not on the Web will not be helpful. 20:43:22 TB: It seems that the Web arch doesn't need to talk about the empirical difference between resource classes. 20:43:23 If you don't do that then you are saying that SW cannot use URI for things not on the web 20:43:44 ack Chris 20:43:52 ack TBray 20:44:09 TB: Something can be used for naming and orthogonally for dereferencing (e.g., namespace names). It's a good thing to be able to decide later. 20:44:22 TB: I still have trouble understanding what breaks with this world view. 20:45:03 RF: If you define a new URI scheme, I can create a proxy that GETs representations in that URI space. 20:45:22 the notion that something should be *defined* as non-dereferencable seems deeply broken to me 20:45:24 I accept Roys proxy argument 20:45:36 q? 20:45:39 RF: Given the way you can use existing applications today, you can't make such distinctions within URI space. 20:45:43 -q 20:46:21 q? 20:46:27 ack Roy 20:46:32 DO: I think we need to be more vigorous when we start putting automated resource representations at end of URis. 20:46:44 q+ to say that the issue is not things which are not on the web, its things which are not information objects on the web (you can't get them by looking them up) but which you can get information *about* by looking them up. 20:48:20 punt 20:48:53 q+ 20:48:55 it's not "at the back of the queue"; it's no longer on the queue. We have decided we can write the arch doc without it. 20:48:59 There are some resources which more or less *are* their representation, e.g. cute-cat.jpg, others clearly not, e.g. XML namespace names. Does the architecture care 20:49:03 ? 20:51:21 http://lists.w3.org/Archives/Public/www-tag/2003Jan/0014.html 20:51:28 "Re: WebArch Ambiguity about Objects, PLUS Suggested Major Replacement 20:51:28 " 20:51:55 bray notes 0014 contains specific suggested text 20:51:57 TB: This is being taken up on www-tag (whether we want it to be or not). I recommend that TBL look at whether there's a way forward there. 20:52:45 ---------------------------------- 20:53:03 XInclude 20:53:21 suggests that this is further evidence that XInclude was a mistake 20:53:24 Content negotiation 20:53:24 http://lists.w3.org/Archives/Public/www-tag/2002Dec/0242.html 20:53:46 Also http://lists.w3.org/Archives/Public/www-tag/2002Dec/0237.html 20:54:08 DC: I would like to see the WG's response first; whether commenter is satisfied. 20:54:44 q? 20:54:53 ack TimMIT 20:54:54 TimMIT, you wanted to say that the issue is not things which are not on the web, its things which are not information objects on the web (you can't get them by looking them up) but 20:54:56 ... which you can get information *about* by looking them up. 20:54:59 ack Ian 20:55:11 ack DanC 20:55:13 DanC, you wanted to ask if the WG has responded to the XInclude comment yet 20:55:27 Ian, please make a link to "the message [Roy]" sent from the TAG events/schedule stuff http://www.w3.org/2001/tag/#news 20:55:37 Action IJ: Put together ftf meeting page. 20:57:56 TB: I will be there all day Friday, mid-afternoon Thursday. 20:58:06 NW: Regrets. 20:58:52 ------------------------------------------ 20:59:10 On a next version of XML. 20:59:19 q+ 20:59:42 Date: Mon, 06 Jan 2003 12:47:49 -0500 20:59:49 http://lists.w3.org/Archives/Member/tag/2003Jan/0007.html 20:59:55 [TAG-only for now] 21:01:26 [DC reads portion of CL's objection.] 21:01:36 q+ 21:01:55 DC: Is XML Base excluded intentionally? 21:01:57 NW: Yes. 21:02:28 CL: XML IDs are not a dying thing. 21:02:33 NW: They are not dying quickly. 21:02:39 ack Chris 21:02:43 CL: I disagree with NW. 21:02:43 the way XPointer uses ID should die. 21:03:19 q+ DanC 21:03:40 [Discussion of use of IDs] 21:04:32 DanC< you queued yourself to say " the way XPointer uses ID should die." 21:04:40 CL: Easier to declare that xml:id is of type ID. If you want anything different, then use DTDs or other validation mechanisms. 21:04:44 in fact for virtually all languages invented at W3C and elsewhere, foo#bar points to 21:05:02 CL: I'm not happy having a subset that says you can't use DOM and XPointer. 21:05:23 CL: I want to separate validation and decoration. 21:05:25 q? 21:06:03 CL: These two concepts were conflated in SGML; we could get this right now. 21:06:24 DaveO has joined #tagmem 21:06:29 q? 21:06:31 CL: There are two separte operations. one is the parsing of the input to produce the infoset. Another is a validation of the document syntax. These were confused in SGML and not quite sepraated in XML. This moves toward fixing this. 21:06:33 q+ 21:06:35 TB: It's too late for xml:id. Every language out there uses "id" to be of type ID. 21:06:56 TB: You could adopt James Clark's solution, or you could bite the bullet and ....[scribe missed] 21:07:05 CL: Another way (also proposed by James) is to say that xml:id is decoration. 21:07:18 TBL: Is this an implicit declaration in all documents? 21:07:24 "...and say that #id means the element with the attribute "id"" 21:07:25 that's xml:idAttr and you say xml:idAttr="id" 21:07:31 I'd like to make a "matrix" suggestion. What are the solutions that we are talking about, and what are there pros/cons? 21:07:31 Bray referred to the decoration idea as "Clark's idattribute" I believe 21:07:33 q+ 21:07:43 TBL: Two ways to do this - declare in namespace, or do by decoration. 21:07:46 s/TBL/CL 21:08:04 CL: I note that content will have to be changed anyway. 21:08:15 TB: All this aside, I think that NW's formulation is correct. 21:08:26 TB: We've muddled along and it doesn't cause practical problems. 21:08:30 [CL: It does.] 21:08:34 Grrrrrrr 21:08:50 TB: The risk of slippery slope for just one new feature is horrendous. 21:08:56 It causes *immense* practicval problems 21:09:01 ack TBray 21:09:15 GetElementByID is the single most used DOM call 21:09:16 I still assert that the two problems are seperable and should be solved seperately 21:09:39 q- DanC 21:09:45 ack DaveO 21:09:50 q+ 21:10:00 I still assert that they are not orthogonal. They are seperable, but not totally orthogonal 21:10:09 DO: I am susceptible to both arguments: no new features v. getting ids correct. 21:10:12 the axes are, like , 70 degrees apart not 90 21:10:17 your point that they're not orthogonal is well made, Chris. 21:10:33 DO: In Web services, lots of "id" attributes being defined over and over (and named "id"). 21:10:43 I agree its well made but TimB does not ... 21:10:44 DO: I'd like us to keep the door open on this particular feature creep. 21:11:06 I accept that they are not properly orthogonal. But they are seperable. The problem exists *now* independent of the subset. 21:11:07 rip the name "id" out of the users' hands I say 21:11:08 DO: I would love it if CL listed the various options for dealing with ids. 21:11:41 ack PaulC 21:11:43 DO: I'd like to keep the issue open to hear the pros and cons. 21:11:47 PC: I agree with DO. 21:11:53 q+ to note that graph-oriented systems can't use xml's id because there is no distinction between definition and use. XML makes the assumption that one occrrence of the id is special. 21:12:15 PC: I have to keep an open mind for other reasons than DO. 21:12:32 q+ 21:13:09 PC: I have some concerns about wording in NW's proposed text about where this work should take place. I think we should make clear that the AC will be deciding this. 21:13:26 NW: I hear that, but think we should suggest something they should agree on. 21:15:34 NW: We can propose two different issues. 21:15:39 ack Norm 21:15:57 a) subsetting XML 21:16:02 b) xml:id 21:16:31 NW: I suggest writing up another draft in TAG space. 21:16:39 quick straw poll on which list to use? 21:16:52 TB: I'd rather this take place on www-tag. 21:17:01 I'm agnostic; light preference for www-tag 21:17:32 CL, PC: One more round on TAG list would be better. 21:17:47 Action NW: Send another draft to tag@w3.org. 21:17:52 q? 21:18:50 TBL: In an RDF document, there's not a defining instance of an id. When something occurs in more than one place, it's considered to be the same thing. 21:18:54 ack TimMIT 21:18:55 TimMIT, you wanted to note that graph-oriented systems can't use xml's id because there is no distinction between definition and use. XML makes the assumption that one occrrence of 21:18:57 ... the id is special. 21:19:01 ack TBary 21:19:04 ack TBray 21:19:28 TB: Why can't you have a new spec that defines a subset? 21:20:00 NW: You could, but if you had a combined document that only defined a subset, then I think the people still using DTDs would be cheated out of that useful body of work. And that two parallel things going forward would be confusing. 21:20:59 &danc; 21:21:14 that's a general entity, not a parameter entity 21:21:33 [Discussion about number of specs.] 21:21:56 q? 21:21:58 TB: I disagree that if you do "grand unification" you would also have to do "all of 1.1". 21:22:14 CL: There's another way to do this - define a small version, and base 1.1 on that. 21:22:17 NW: That's what I had in mind. 21:22:29 CL: You include the subset by reference (in the 1.1 draft). 21:22:51 NW: The two points I want to make are (1) I think that will be a lot of work and (2) I would be uncomfortable *not* doing it. 21:22:56 Sounds as though we have 3 useful tasks. 1) subsetting 2) xml:ids 3) unification of specs without changing anything else 21:23:49 TB: I am not comfortable with "MUST do all of 1.1." 21:24:04 TB: I am fine with two statements (1) big job and (2) might be problematic if only include subset. 21:24:12 ------------------------------------- 21:24:14 Action item review 21:24:21 # Status of URIEquivalence-15, IRIEverywhere-27. 21:24:27 # 21:24:27 1. Action MD 2002/11/18: Write up text about IRIEverywhere-27 for spec writers to include in their spec. 21:24:27 2. Action CL 2002/11/18: Write up finding for IRIEverywhere-27 (from TB and TBL, a/b/c), to include MD's text. 21:24:43 CL: Whoops! 21:25:12 SW: Please have an update for 13 Jan. 21:25:13 # 21:25:13 1. 21:25:13 6. 21:25:13 # binaryXML-30 21:25:13 1. Action CL 2002/12/02: Write up problem statement about binary XML; send to www-tag. 21:26:08 # 21:26:08 2. 21:26:08 1. TB's "How to Compare Uniform Resource Identifiers" draft finding. 21:26:13 http://www.textuality.com/tag/uri-comp-2.html 21:26:25 ack DanC 21:26:26 DanC, you wanted to offer to review "How to Compare Uniform Resource Identifiers" draft finding 21:26:35 q+ 21:27:13 PC: There are four software groups at MS who are looking at your draft; I need some more review time. 21:27:46 -------- 21:27:51 RDDL challenge 21:28:03 NW Action : 21:28:04 http://lists.w3.org/Archives/Public/www-tag/2003Jan/0004.html 21:28:14 oops; norm sent something? darn; I thought I was watching for that 21:28:19 NW: They're all adequate. Just pick one. I picked Jonathan's proposal. 21:28:27 q+ 21:28:48 ack Roy 21:28:50 ack PaulC 21:28:52 q+ to say I now like Sandro's proposal 21:28:53 RF: WHy do we need to pick one? 21:29:04 PC: What's http content negotiation all about? 21:29:12 PC: Why aren't image formats similar? 21:29:17 TBL: You need dominant image formats. 21:29:23 (i.e.. let the market decide which one dominates) 21:29:35 PC: I am not sure that having a single format is the right answer. 21:29:56 q+ 21:29:59 I am increasingly convinced that a single format is desirable 21:30:26 I am increasingly convinced that I don't know which is better. 21:30:49 TB: We can't say "you MUST use X" but it would be a benefit to the community to bless one format. 21:30:57 TB: Also, check out Sandro's suggestion.... 21:31:47 conneg and separate URIs are not exclusive! 21:31:52 you can do both. 21:32:10 q+ 21:32:20 Big general discsuusion, old one, pros and cons. 21:32:35 ack TBray 21:32:36 TBray, you wanted to say I now like Sandro's proposal 21:32:41 ack Chris 21:32:51 ack TimMIT 21:33:48 Adjourned 21:33:55 -Norm 21:33:56 RRSAgent, stop