19:52:17 RRSAgent has joined #tagmem 19:52:26 Zakim, this will be tag 19:52:26 ok, Chris; I see TAG_Weekly()2:30PM scheduled to start 22 minutes ago 19:53:38 Stuart has joined #tagmem 19:56:33 Ian, in http://www.w3.org/2001/tag/issues.html?view=normal&closed=1 why does uriMediaType-9 show an open action for me? 20:00:09 DanC has joined #tagmem 20:00:27 TAG_Weekly()2:30PM has now started 20:00:28 +Chris 20:00:35 Roy has joined #tagmem 20:01:42 +??P0 20:01:43 -??P0 20:01:44 +??P0 20:01:49 zakim, ??p0 is me 20:01:49 +Stuart; got it 20:01:58 Ian has changed the topic to: http://www.w3.org/2003/12/01-tag.html 20:02:12 +??P1 20:02:35 zakim, call Ian-BOS 20:02:35 ok, Ian; the call is being made 20:02:37 +Ian 20:02:37 zakim, ??p1 is Paul 20:02:38 +Paul; got it 20:03:12 +DanC 20:03:21 zakim, mute paul 20:03:21 Paul should now be muted 20:03:33 zakim, drop DanC 20:03:33 DanC is being disconnected 20:03:34 -DanC 20:03:43 We got your ans. mach 20:04:08 zakim, who is here? 20:04:08 On the phone I see Chris, Stuart, Paul (muted), Ian 20:04:09 On IRC I see Roy, DanC, Stuart, RRSAgent, Zakim, Chris, Ian 20:04:11 +Roy_Fielding 20:04:12 +DanC 20:04:15 timbl has joined #tagmem 20:04:24 -Paul 20:04:43 +TimBL 20:05:58 +Tim_Bray 20:06:12 down with what, Stuart? 20:06:21 TBray has joined #tagmem 20:06:32 Roll call: SW, TBL, IJ, CL, DC, RF, TB, PC 20:06:36 Regrets: NW 20:06:42 Not sure: DO 20:06:43 +PaulC 20:06:51 en-gb:lurgy = en-us:cold? 20:06:57 zakim, mute PaulC 20:06:57 PaulC should now be muted 20:07:21 [DC agrees to Chair] 20:07:27 zakim, mute paulc 20:07:27 PaulC was already muted, Stuart 20:07:31 Agenda: http://www.w3.org/2003/12/01-tag.html 20:07:57 Accept the minutes of the 15-17 Nov ftf meeting? 20:08:11 http://www.w3.org/2003/12/15-tag-summary.html 20:08:18 CL: I propose to accept. 20:08:21 TBray: yep, looked ok 20:08:46 zakim, unmute paul 20:08:46 PaulC should no longer be muted 20:08:56 Resolved: Accepted. Abstaining: TBL, PC 20:09:01 zakim, mute paul 20:09:01 PaulC should now be muted 20:09:05 Accept the minutes of the 24 Nov teleconf? 20:09:18 http://www.w3.org/2003/11/24-tag-summary.html 20:09:31 Resolved to accept. 20:09:36 (those minutes). 20:10:02 DC: Comments on today's agenda? 20:10:10 -PaulC 20:10:13 Reminder: next meeting 4 Dec. 20:10:18 SW will Chair. 20:10:26 TBL: I will not be able to make the first five minutes. 20:10:44 DC: Backup chair? 20:11:04 Reminder: teleconf is 8am PT/11am ET 20:11:08 (on 4 Dec) 20:11:13 CL reconfirms. 20:11:42 I think I'm available 20:12:04 SW: IJ and I will produce agenda tomorrow. 20:12:09 Video meeting in Feb 2003: 20:12:09 1. Action SW/PC 2003/11/10: Explore possibility of TAG videolink TAG distributed meeting in February. 20:12:14 [Postpone discussion] 20:12:18 +PaulC 20:12:25 # 20:12:25 1. 20:12:25 # Tech Plenary 20:12:28 1. Action SW 2003/11/15: Take to tech plenary committee the TAG's proposal. 20:12:32 SW: I've completed that action. 20:12:41 zakim, mute paul 20:12:41 PaulC should now be muted 20:13:07 +DOrchard 20:13:17 SW: I've not received a response yet from the committee. 20:13:28 SW: The planning committee has yet to meet. 20:13:45 Negotiations with WGs for last call: 20:13:45 1. SW/I18N done 20:13:45 2. Schema/PC done. MSM has confirmed. 20:13:45 3. SVG/CL done 20:13:46 4. HTML/IJ done 20:13:48 5. Todo: Voice/SW, XML Core/NW, WSDL/DO 20:14:04 SW: I have not received reply from I18N WG yet. 20:14:12 IJ: I have not yet received reply from HTML WG. 20:14:29 CL: Loop is closed with SVG WG. 20:14:43 SW: No progress with Voice yet. 20:14:48 [NW not here for Core] 20:15:17 DO: No progress yet. 20:15:20 ===== 20:16:00 Comments on 28 Nov 2003 WD of the Arch Doc? 20:16:18 http://www.w3.org/2001/tag/2003/webarch-20031128/ 20:17:08 Proposal: Withdraw this actino item for v 1.0 Arch Doc: 20:17:15 Action IJ 2003/10/08: Starting from DO's diagram, create a diagram where the relationships and terms are linked back to the context where defined. Ensure that the relationships are in fact used in the narrative; any gaps identified? With DO, work on term relationship diagram. 20:17:23 SW, TB, TBL: Seconded. 20:17:28 Resolved: Withdrawn. 20:17:45 Action IJ 2003/11/15: Close issue 6 with TB proposed text. (Done) Inform reviewer. (Not done) 20:18:02 IJ: Otherwise I think the actions have been done in the 28 Nov draft. 20:18:19 CL: I did my actions 1., 2. Number 3 is not yet done. 20:19:20 IJ: I believe CL's actions also incorporaetd in 28 Nov draft. 20:19:35 IJ: I believe NW's 2/3 actions also incorporaetd in 28 Nov draft. 20:19:47 DC: We don't know whether they have been incorporated to NW's satisficastion. 20:19:55 NW's actions recorded as done. 20:20:04 1. Completed action TB: Rewrite paragraph on ambiguity in section 2.2. 20:20:16 Action RF 2003/10/08: Explain "identifies" in RFC 2396. 20:20:26 RF: The existing draft expires this week...I'd better do it... 20:20:29 Resolved: Continued. 20:20:39 Completed Action DO/TBL 2003/11/15: Produce new text for a small subsection 1.2.4 (or perhaps for 1.2.1) 20:20:58 DO: 2/3 not doen. 20:21:09 DaveO has joined #tagmem 20:21:35 IJ: I incorporated TBL/DO text in 28 Nov draft; they haven't signed off yet. 20:22:09 http://www.w3.org/2001/tag/2003/webarch-20031128/#general 20:22:17 (section 1.2.2) 20:22:32 DC: DO's action on WSDL WG continued. 20:22:39 DC: DO's action 3 continued. 20:23:05 TBray: DO, do you regard this as important for LC? 20:23:19 DO: I am fine with this not being done for LC. 20:23:27 DO: Please continue (indefinitely). 20:23:54 1. Action TBL 2003/07/14: Suggest changes to section about extensibility related to "when to tunnel". 20:24:05 TBL: Please continue indefinitely (after LC). 20:24:08 IJ: I'll move to issues lsit. 20:24:25 Completed action DC 2003/11/15: Elaborate on value of orthogonality of specs in section 1.2.1 including example HTTP/HTML 20:24:33 DC: Done to my satisfaction. 20:24:46 IJ: I expanded on it as well in 28 Nov draft. 20:25:15 IJ: Please see my discussion on META/refresh in that section. 20:25:37 1.2.1. Orthogonal Specifications 20:25:40 http://www.w3.org/2001/tag/2003/webarch-20031128/ 20:25:41 http://www.w3.org/2001/tag/2003/webarch-20031128/#general 20:26:09 TBray: CL and I had some back and forth on this. 20:26:10 and http-equiv="refresh now" 20:26:21 TBray: I like the motherhood and apple pie language before the bulleted list. 20:26:22 " The HTML specification allows content providers to instruct HTTP servers to build response headers from META element instances. This is a clear abstraction violation; the developer community deserves to be able to find all HTTP headers from the HTTP specification (including any associated extension registries and specification updates per IETF process). Furthermore, this design has led to confusion in user agent development. The HTML specification state 20:26:43 TBray: I think the first sentence needs rephrasing. 20:26:55 TBray: the HTML spec supplements HTTP servers. 20:27:08 CL: In fact, the HTML spec is an instruction for HTTP servers, which is universally ignored. 20:27:18 CL: That's evidence of a problem having arisen. 20:27:33 TBray: Perhaps a bit of phrasing "This doesn't work in deployed servers as specified!" 20:27:52 3rd bullet: " Some authors use the META/http-equiv approach to declare the character encoding scheme of an HTML document. By design, this is a hint that an HTTP server should emit a corresponding "Content-Type" header field. In practice, the use of the hint in servers is not widely deployed and many user agents peek inside the HTML document in preference to the "Content-Type" header field. This works against the principle of authoritative representation m 20:28:41 Action IJ: Salt this text to taste to emphasize that problems have arisen. 20:28:44 emph " servers is not widely deployed " 20:28:57 RF: There are servers that implement it! 20:29:13 RF: [Some] Content management systems do this. 20:29:15 s/!// 20:29:21 content magagement systems, and the discontinued GN server 20:29:21 s/!/FYI/ 20:29:47 DC: My action 2 done; action now on IJ. 20:29:54 My action 3 is done. 20:29:55 /me just froggy throat from cold 20:30:01 DC: My action 3 is done 20:30:05 DC: Please continue action 4. 20:30:13 Action SW: 2003/11/15: Verify that "agent" is used consistently in the document and makes sense as both people and software. [Subsumed by IJ?] 20:30:16 TBray: Better than it used to be. 20:30:19 IJ: I agree with TB. 20:30:33 SW: Please continue my action 1. 20:30:55 Action IJ: Please link to SW's photos from the 15 Nov minutes. 20:31:01 SW's action 2 is closed. 20:31:27 yes, i agree 20:31:30 [On text in 1.2.2] 20:31:45 yes, i agree that a sentence of introduction would be helpful 20:32:07 TBL: The gist is missing: It's not just enough to make an extension language, you also need to make it so that not only old documents members of the new language, but also that new docs, without much damage, can be interpreted in the old language. 20:32:35 TBL: Ok that extension is inverse of subset. 20:33:03 TBL: Missing text is that you need to ensure that a doc in the extension language can be interpreted in the old language with predictable results. 20:33:42 "second" and "first" is ambiguous 20:34:15 TBL: Should be in para about "Language extension". 20:34:33 I note "we", the TAG decided on whatever timbl, daveo, and Ian agree to. 20:35:33 http://www.w3.org/2001/tag/2003/webarch-20031111/tim 20:35:56 "Clearly, an extension language is better than an incompatible language, but in practice greater compatability is needed. Ideally, an instance of the superset language, in many cases can be safely and usefully processed as though it were in the subset language. Extensability the property of a langauge that allows this. The original language design can accomplish extensability by defining, for predicable unknown extensions, the handling by implementations -- for 20:36:01 Language A' is an extension of language A if and only if A is a subset of A'. 20:36:29 ack tbray 20:36:29 TBray, you wanted to comment on the draft 20:36:39 TBray: I sent email (URI?) with comments on the draft. 20:37:17 http://lists.w3.org/Archives/Public/www-tag/2003Nov/0076.html 20:37:43 TBray: I think CL and I agree that most of the issues are probably not controverial. 20:37:51 CL: I agree with TB's assessment. 20:38:09 [TB has the floor] 20:38:22 my response at http://lists.w3.org/Archives/Public/www-tag/2003Dec/0018.html 20:38:36 1.2.4 Is the 2nd sentence of the first para, about the longevity of 20:38:36 messages, new in this draft? It doesn't have anything to do, not in 20:38:36 the slightest, with the actual point being made in this section. 20:38:42 q+ to talk about https if we get there. 20:39:09 TBray: Propose to lose that sentence. 20:39:12 CL: Fine to drop. 20:39:58 Action IJ: s/messages exchanged/technology shared. 20:40:16 "the technology shared among agents in the Web may last 20:40:17 longer than the agents themselves" would also be fine. 20:40:38 TBray: I propose that second para be dropped. 20:40:48 whoops. 20:40:52 First sentence only? 20:41:03 TB proposal: Rewrite first sentence per CL proposal. 20:41:08 So, I agree 20:41:09 with Tim about loosing the last para, but also suggest deleting "not 20:41:09 in terms of APIs or data structures or object models, but in terms of 20:41:09 protocols,". Make a positive point about the benefits of message based 20:41:09 interop, its not necessary to knock other approaches to make the 20:41:09 point. 20:41:18 ian does now 20:42:09 s/content and sequence/content,sequence and semantics/ 20:42:13 deletion proposed *is* in IRC 20:43:33 s/not in terms of APIs or data structures or object models, but// 20:43:43 (in FIRST para) 20:44:01 "The Web follows Internet tradition in that its important interfaces are defined in terms of protocols, by specifying the content and sequence of the messages interchanged." 20:44:10 TBL: I'd like semantics to go in para. 20:44:13 TBray: I can live with semantics. 20:44:18 "The Web follows Internet tradition in that its important interfaces are defined in terms of protocols, by specifying the content, sequence and semantics of the messages interchanged." 20:44:24 The Web follows Internet tradition in that its important interfaces are defined by specifying the content and sequence of the messages interchanged. 20:44:29 The Web follows Internet tradition in that its important interfaces are defined in terms of protocols, by specifying the content, sequence, and semmantics of the messages interdchanged. 20:45:30 s/content, sequence and/syntax, semantics, and sequence/ 20:45:30 The Web follows Internet tradition in that its important interfaces are defined by specifying the content, sequence and semantics of the messages interchanged. 20:45:40 I'm OK with that 20:45:43 ok 20:45:44 CL: Fine. 20:45:47 +1 to roy 20:46:06 timbl has joined #tagmem 20:46:10 The Web follows Internet tradition in that its important interfaces are defined in terms of protocols, by specifying the syntax, semantics, and sequence 20:46:17 ...of the messages interchanged 20:46:29 go for it 20:46:30 Resolved: Accept TB's sentence. 20:46:47 Proposed: Drop third para. 20:46:51 Resolved: Drop third para. 20:47:07 RRSAgent, pointer? 20:47:07 See http://www.w3.org/2003/12/01-tagmem-irc#T20-47-07 20:47:11 rrsagent, pointer? 20:47:11 See http://www.w3.org/2003/12/01-tagmem-irc#T20-47-11 20:47:24 TBray: 2. Would anyone else like to tighten up the first para by retaining 20:47:24 just the first and last sentences? It would be immensely clearer I 20:47:24 think. 20:47:40 Parties who wish to communicate must agree upon a shared set of identifiers and on their meanings. Thus, Uniform Resource Identifiers ([URI], currently being revised) which are global identifiers in the context of the Web, are central to Web architecture. 20:48:24 CL: I'm ok with losing second sentence... 20:48:28 /me diff's are so much clearer 20:48:51 I am fine with Tim Brays text 20:48:59 I note that this value bit comes back later in the section on ambiguity. 20:49:55 DC: I meant "network effect" sentence as motivation for first constraint. 20:50:22 q+ to comment. 20:50:58 ack ian 20:50:58 Ian, you wanted to talk about https if we get there. and to comment. 20:51:37 IJ: There's a tie-in in 2.3 in section on ambiguity. 20:51:46 DC: I don't like first para of 2. 20:51:55 CL: +1 to TB's proposal. 20:52:57 TBL: Delete 2nd sentence, leave third. 20:53:02 yay! 20:53:04 (of first para of section 2) 20:53:12 Resolved: Delete sentence two of first para of 2. 20:53:14 resolved 20:53:50 TBray: I don't understand "Of particular importance are those messages that express a relationship between a URI and a representation of the resource it identifies. " 20:53:56 DC: Those are "200 Ok" responses. 20:53:59 TBray: Then please send that. 20:55:00 q+ 20:55:58 IJ Proposal: Clarify intent of sentence in question as last sentence of para of 2.2. 20:56:16 seems redundant to the sentence following it 20:56:22 DC: The point is that the way URIs take on meaning is that you get representations back when you deref the URI; 200 Ok reponses are thus key. 20:57:02 q+ 20:57:06 ack ian 20:57:43 yes, but doing well I think, have covered most of my hot-button issues 20:58:00 DC: I'm ok to lose the sentence, having heard RF. 20:58:25 Proposal to delete "Of particular importance are those messages that express a relationship between a URI and a representation of the resource it identifies." 20:58:25 okay 20:58:28 CL: ok 20:58:29 DC: Ok 20:58:30 TBray: Ok 20:58:42 TBL: Ok 20:58:50 ok 20:58:50 Resolved: Delete said sentence of 2.2. 20:59:04 s/URI ownership URI/URI ownership 20:59:06 [Noted] 20:59:29 3.2. Messages and Representations 20:59:40 TBray: I propose change to read: 20:59:48 q+ 20:59:55 Some is about the resource, some is specific to a particular resource 20:59:55 representation. 20:59:56 A messsage may include: data, metadata about the data, and metadata about the resource. 21:00:14 CL: My point was that some is about the resource, some about the representation. 21:00:22 CL: E.g,. content-language is about the representation. 21:00:28 q+ 21:01:00 TBray: Change to "metadata about the representation data" 21:01:50 we need to say both - resouece and representation metadata 21:02:14 'Vary' for example is about the resource 21:02:20 ack chris 21:02:21 TBL: Simplify to metadata about the resource and the message. 21:02:29 may include data and metadata about the resource and the message. 21:02:34 ack chris 21:02:35 ack ian 21:03:07 by "general" do you mean "typical"? 21:03:08 IJ: I moved "resource metadata" out of ordered list since not the general case. 21:03:09 message ~= message metadata, representation, represenation metadata and resource metadata? 21:03:37 may include representation data as well as metadata about the resource, the representation, and the message. 21:03:49 Propose: A message may include data, and metadata about the resource and the message. 21:04:21 +1 to TBray's draft 21:04:22 CL, DC: We prefer TB's proposal. 21:04:27 prefer tbrays one 21:04:44 prefers TBray's draft 21:04:46 A message may... 21:04:50 consensus! 21:05:03 RESOLVED 21:05:05 Resolved to accept TB"s proposal. 21:05:33 TB Proposal: Lose GPN just before 3.5 21:05:35 Lose GP at end of 3.4.1 21:05:56 TBray: We say the same thing in preceding para (as in GPN) 21:05:59 "Server managers MUST ensure that resource 21:05:59 metadata is appropriate for each representation." 21:06:16 This is not the responsibility of server managers. 21:06:19 s/appropraite for each represnetation/correct 21:06:24 how about s/approriate/accurate/ 21:06:45 s/each/all 21:06:45 s/each/all the/ 21:06:47 q+ 21:06:51 CL: My point is that if your metadata says something about a resource, make sure it works for all representations. 21:06:58 ack Roy 21:07:07 RF: I don't think this is appropriate at all. It's not the server manager's responsibility. 21:07:29 RF: A server manager is incapable of knowing all the resources in the server namespace. 21:07:36 q+ 21:07:39 RF: The metadata depends on how the author intends a resource to be used. 21:07:45 (through representations). 21:08:03 q+ to point out that we can't really go into the disnction between different parties in the publisher. 21:08:03 ack timbl 21:08:04 timbl, you wanted to point out that we can't really go into the disnction between different parties in the publisher. 21:08:20 TBL: I think that RF's distinction is between different parties within the publisher (abstraction). 21:09:00 IJ proposal to either add "metadata, especially that applying across representations" and deleting GPN. 21:09:02 q+ to argue that distinguishing between resouce and representation is the crucial thing; drop 'server manager' 21:09:58 +1 to what Ian said 21:10:03 ok now to drop the box 21:10:15 ack chris 21:10:15 Chris, you wanted to argue that distinguishing between resouce and representation is the crucial thing; drop 'server manager' 21:10:32 Proposed rewrite of sentence before GPN: Furthermore, server managers can help reduce the risk of error through careful assignment of representation metadata (especially that which applies across representations)." 21:10:36 (and delete GPN). 21:10:49 so RESOLVED. 21:11:13 q+ 21:11:19 q- 21:11:43 3.5 Why the new XForms plug? It adds nothing to the example and 21:11:43 creates confusion because people are going to wonder if this is special 21:11:43 and different and couldn't have been done with old-fashioned HTML 21:11:44 forms. Must be removed. 21:11:44 q+ 21:11:44 suggestion: Resource owners must manage the resource's provided metadata as carefully as they manage the data, ensuring that they remain consistent with the intended semantics of the resource. 21:12:16 TBray: Move back from Xforms to HTML forms. 21:12:38 TBray: Might make people think that you need Xforms to do this. 21:12:46 CL: Propose "for example" around Xforms. 21:12:49 TBray: I'm fine with that. 21:12:55 add "for example' right before xforms 21:12:55 +1 21:12:58 Proposed: "Built with, for example, XForms") 21:13:16 RF: I think the idea is good, not sure it improves readability. 21:13:19 (built with XForms ro HTMl forms) 21:13:47 OK with TBL's too 21:13:57 q+ to say it makes a link to a finding 21:13:59 q- 21:14:00 simple is better 21:14:14 TBray: Propose to lose parenthetical 21:14:22 Could we see the text we agreed on at the f2f in the 111? 21:14:26 DC: +1 to lose parenthetical 21:14:31 RF: +1 to lose parenthetical 21:14:43 Resolved: Lose parenthetical re: xforms. 21:14:45 q? 21:14:46 ack Chris 21:14:46 Chris, you wanted to say it makes a link to a finding 21:15:23 DC: Finding is cited in last para of the section. 21:15:55 4.2.2 "must understand". I totally don't agree that "must understand" 21:15:55 is limited to markup from another namespace. XHTML could for example 21:15:55 have applied a "must understand" policy to new XHTML elements (they may 21:15:55 have, for all I know). All you need to do is /markup from an 21:15:55 unrecognized namespace/unrecognized markup/ 21:16:32 DO: That's correct. 21:17:01 CL: Namespace can be relevant. 21:17:45 CL:You could have different handling whether in or out of namespace (and unrecognized). 21:17:58 q+ 21:18:13 q- 21:18:21 q+ to say that "including mixing strategies" appears in next para. 21:18:26 http://lists.w3.org/Archives/Public/www-tag/2003Nov/0074.html 21:18:59 TBray: CL's example is deceiving. It's a particular example. 21:19:09 TBray: CL's example is less simple. 21:19:13 DO: +1 to TB 21:19:16 TBL: +1 to TB. 21:19:29 Resolved to accept TB's proposal. 21:19:47 4.3 The para beginning "Note that when content, presentation, and 21:19:47 interaction are separated" is *very* fuzzy and I think could just be 21:19:47 nuked. I don't remember discussing this, is it the output of TAG 21:19:47 discussion? 21:19:48 q? 21:19:48 q- 21:19:51 q+ to talk about https 21:20:11 TBray proposes to delete para "Note that when content, presentation, and interaction ..." 21:20:30 CL drafted it, Ian rewrote it 21:20:48 TBray: I withdraw my comment. 21:21:03 4.5.2 is the TAG comfy with being this much in favor of XPointer? I'd 21:21:03 need to hear a few explicit "YESes" 21:21:26 To define fragment identifier syntax, use at least the XPointer Framework and XPointer element() Schemes. 21:21:36 TBL's text was this: "XLink is an appropriate specification for representing links in hypertext XML applications. 21:21:36 " 21:22:11 4.5.2. 21:23:55 Please condense all four paragraphs of 4.5.2 into one. 21:24:08 +1 to Roy 21:24:28 TBL proposal: Move "XLink is an appropriate specification for representing links in hypertext XML applications." to 4.4 21:24:35 I think that 4.5.2 is fine as it is 21:24:48 Support for move: TB 21:25:06 TB, CL: Leave where it is. 21:25:08 better where is is 21:25:42 TBL: Proposed change title of section to 4.5.2to "Hyperlinks in XML" 21:26:30 q+ to return to the xpointer-assertion sentence & make sure we cleaned that up 21:26:33 q- 21:26:48 Propose moving "XLink is an appropriate specification for representing links in hypertext XML applications." to before " XLink allows links to have multiple ends" 21:27:21 Middle of 1st para of 4.5.2 21:27:24 TBL: I think that makes sense.......... 21:27:27 establishes a hypertext context 21:27:44 IJ proposes louder back link to hypertext. 21:27:49 section 21:27:51 editorial: s/( in | for ) XML// for all section headings 4.5.* 21:28:02 IJ summarizing: 21:28:10 +1 to Roy 21:28:14 1) s/use at least/consider 21:28:26 2) move third para to first para per CL proposal. 21:28:33 3) Link back to hypertext links section. 21:28:36 (all in 4.5.2) 21:28:47 TBray: +1 21:28:48 TBL: +1 21:29:01 SW: Don't use "consider" twice in same para. 21:29:03 [Editorial] 21:29:10 yes we do 21:29:30 =================>Ian 21:29:31 "specifically" might help, yes. 21:29:36 Resolved: Accept IJ proposal. 21:29:51 4.5.5 2nd para, 2nd sentence is COMPLETELY WRONG. Yes, you can convert 21:29:51 back & forth between qunames & URI/local-part pairs. What you can't do 21:29:51 is go back & forth from qnames to URIs; which is clearly what Norm 21:29:51 meant. 21:30:07 TBray: Yes there is. What there isn't is qname -> URI. 21:30:26 There is no single, accepted way to convert a QName into a URI or vice-versa. 21:30:32 There is no single, accepted way to convert a QName into a URI. 21:30:46 don't lose vice-versa please 21:30:54 OK chris? 21:31:08 SW, TBL: Qualified names and QNames are different. 21:31:30 First sentence defines them as same. 21:31:31 TBray: I think SW is right. 21:31:35 Propose s/("Qnames")// 21:31:49 section is called "4.5.5. QNames in XML" so no ambiguity... 21:32:23 IJ: I am confused seeing qualified name , then qname, then not understanding the relation. 21:32:37 TBray: Nuke "QName", then insert a sentence explaining relation. 21:33:19 /me I need to go, but please continue without me 21:33:23 TBL: "Qualified names were introduced by XMLNS and are represented in XML by the "Qname" construct." 21:33:24 thanks, roy 21:34:01 IJ: I understand the proposed change the goal of ensuring that text is not inconsistent. 21:34:18 PROPOSED: to fix QName stuff to the satisfaction Lilley and Williams 21:34:35 TBray: +1 21:34:36 so RESOLVED. 21:34:47 Roy has left #tagmem 21:34:49 Action IJ: Do another draft. 21:34:53 (before Thursday) 21:35:07 ADJOURN. 21:35:11 RRSAgent, stop