IRC log of tagmem on 2002-06-10

Timestamps are in UTC.

17:01:48 [RRSAgent]
RRSAgent has joined #tagmem
17:01:52 [Zakim]
Zakim has joined #tagmem
17:13:11 [chris]
chris has joined #tagmem
17:13:17 [chris]
chris has joined #tagmem
17:44:47 [DanC]
DanC has joined #tagmem
18:35:26 [timmit]
Zakim, this is tag
18:35:27 [Zakim]
ok, timmit
18:36:09 [timmit]
timmit has changed the topic to:
18:51:33 [DanC]
er... could use some examples.
18:55:51 [timmit]
Zakim, who is here?
18:55:52 [Zakim]
On the phone I see TimBL
18:55:53 [Zakim]
On IRC I see DanC, Zakim, RRSAgent, Ian, timmit
18:59:49 [Roy]
Roy has joined #tagmem
19:00:34 [Ian]
zakim, what's the code?
19:00:35 [Zakim]
the conference code is 0824, Ian
19:00:48 [Zakim]
19:00:57 [Ian]
zakim, who's here?
19:00:59 [Zakim]
On the phone I see TimBL, Ian
19:01:00 [Zakim]
On IRC I see Roy, DanC, Zakim, RRSAgent, Ian, TimBL
19:01:43 [Zakim]
19:02:08 [TBray]
TBray has joined #tagmem
19:02:20 [Zakim]
19:03:46 [Zakim]
19:03:55 [Norm]
Norm has joined #tagmem
19:04:13 [Zakim]
19:04:34 [Zakim]
+ +
19:04:45 [Ian]
19:04:45 [Ian]
IJ to scribe.
19:04:46 [Ian]
TB: Anti-aliasing thing.
19:04:59 [Ian]
zakim, ??P6 is David
19:05:00 [Zakim]
+David; got it
19:05:06 [Ian]
zakim, who's here?
19:05:07 [Zakim]
On the phone I see TimBL, Ian, Tim.Bray, PCotton, ??P4, David, +
19:05:08 [Zakim]
On IRC I see Norm, TBray, Roy, DanC, Zakim, RRSAgent, Ian, TimBL
19:05:13 [Zakim]
19:05:19 [Ian]
zakim, ??P4 is Norm
19:05:20 [Zakim]
+Norm; got it
19:05:36 [Ian]
zakim, aaaa is David
19:05:37 [Zakim]
+David; got it
19:05:41 [Ian]
zakim, who's here?
19:05:42 [Zakim]
On the phone I see TimBL, Ian, Tim.Bray, PCotton, Norm, David, David.a, DanC
19:05:43 [Zakim]
On IRC I see Norm, TBray, Roy, DanC, Zakim, RRSAgent, Ian, TimBL
19:05:48 [Ian]
zakim, David is Roy
19:05:49 [Zakim]
+Roy; got it
19:05:54 [Ian]
zakim, who's here?
19:05:55 [Zakim]
On the phone I see TimBL, Ian, Tim.Bray, PCotton, Norm, Roy, David.a, DanC
19:05:56 [Zakim]
On IRC I see Norm, TBray, Roy, DanC, Zakim, RRSAgent, Ian, TimBL
19:06:00 [timbl_]
timbl_ has joined #tagmem
19:06:17 [Ian]
Regrets: Chris, Stuart.
19:06:23 [timbl_]
Zakim, Stuart send regrets
19:06:24 [Zakim]
I don't understand 'Stuart send regrets', timbl_. Try /msg Zakim help
19:06:27 [PaulC]
PaulC has joined #tagmem
19:06:36 [Ian]
Tim, are you chairing?
19:06:43 [Ian]
19:07:12 [Ian]
Roll call: TimBL, Tim Bray, Norm, Paul, Roy, David, Ian, DanC
19:07:21 [Ian]
3. Accept this agenda?
19:07:27 [TimBL]
RRSAgent, pointer?
19:07:27 [RRSAgent]
19:07:49 [Ian]
NW: Stuart said he might get here.
19:07:58 [Ian]
DO: Paul, can you tell me whether the XMLP response to the TAG was posted?
19:08:30 [Ian]
IJ: This is on the agenda.
19:08:43 [Ian]
TBL: agenda accepted.
19:08:48 [Ian]
Next meeting? Proposed 17 June.
19:08:51 [DanC]
I'm available for 17Jun
19:09:18 [Ian]
(No regrets)
19:09:28 [TBray]
I like that... "no regrets"
19:09:46 [Ian]
TimBL: Proposes moving meeting 30 minutes earlier.
19:09:59 [Ian]
TB: I don't think 30 mins works earlier for Europeans.
19:10:09 [Ian]
Resolved: Leave teleconf at 3pm ET.
19:10:18 [Ian]
5. Accept 3 June minutes
19:10:24 [Ian]
19:10:34 [Ian]
DC: One question:
19:11:01 [Ian]
DC: We made a decision without consensus (internet media type finding despite Tantek's objection).
19:11:24 [Ian]
19:11:40 [Ian]
[[[This document has been produced by the W3C Technical Architecture Group (TAG). The TAG approved this finding at its 3 June 2002 teleconference. The TAG originally reached consensus on this issue at its 28 Jan 2002 teleconference, and after its 20 May 2002 teleconference announced to www-tag. The TAG notes that Tantek lik expressed dissent about this finding.]]]-- TAG Finding: Internet Media Type registration, consistency of usehttp://www.w3.o
19:11:40 [Ian]
rg/2001/tag/2002/0129-mimeThu, 06 Jun 2002 16:48:00 GMT
19:11:54 [Ian]
TBL: Did anyone on the TAG represent that point of view?
19:11:57 [Ian]
19:12:11 [Ian]
TBL: So what do we do w.r.t. people we have decided to disagree with.
19:12:19 [Ian]
TB: See Tantek's more recent posting:
19:12:36 [Ian]
19:12:58 [Ian]
IJ: I put a clue to objection in both the issues list and the finding.
19:13:00 [Ian]
DanC: I'm happy.
19:13:14 [Ian]
ACCEPTED: 3 June minutes.
19:13:22 [Ian]
19:13:24 [Ian]
Accept summary of TAG activity in May 2002 (TAG only)?
19:13:29 [Ian]
TB: I read. sounds fine.
19:13:34 [Ian]
DanC: I skimmed it.
19:14:23 [Ian]
IJ: As structured, this could almost be done mechanically.
19:14:30 [DanC]
whee... boilerplate summaries... not exactly the best for getting attention. I suppose that's by design.
19:15:11 [Ian]
PC: AC reps can distribute this in their company; one click away from info seems fine to me.
19:15:18 [Ian]
ACCEPTED: Summary of TAG activity.
19:16:40 [DanC]
19:16:58 [Ian]
19:17:00 [Ian]
2.1 New issues?
19:17:35 [Ian]
DanC: Did TB mean to raise an issue when pointing to James Clark info?
19:18:01 [Ian]
TB: This is not meant to be an issue. Just a heads-up to read something as value.
19:18:12 [Ian]
DanC: Keep in mind that this encourages people to do the same.
19:18:13 [DanC]
19:18:39 [Ian]
DC: I have too much mail.
19:19:21 [Ian]
DC: Please put under namespaceDocument-8.
19:19:34 [DanC]
seems relevant to
19:19:58 [Ian]
Action IJ: Add link to background info to namespaceDocument-8.
19:20:26 [Ian]
No new issues.
19:20:29 [Ian]
19:20:36 [DanC]
(I don't agree with James, in case that needed saying)
19:21:41 [DanC]
phpht. order?
19:21:55 [Ian]
TB: There was a message from James to the IETF recommending either XML Schema or Relax NG (and argued the advantages of Relax NG).
19:22:25 [DanC]
folks who are riffing on this stuff, pls don't complain when we don't get to stuff later in the agenda.
19:23:36 [DanC]
I agree that RELAX-NG is better in lots of cases; I don't agree that means you shouldn't ever put XML Schemas at the end of namespace pointers.
19:24:04 [DanC]
i.e. just because there are lots of schema languages doesn't mean you shouldn't use any of them for your namespace document.
19:24:08 [Ian]
DO: Relax NG has some interesting and positive architectural aspects to it. We should allow multiple schema languages. I don't think the TAG should weigh in on this.
19:24:22 [Ian]
TB: I think that Relax NG is excellent and XML Schema is not as good on some fronts.
19:24:35 [Ian]
PC: There are some things (w.r.t. XML Query) that Relax NG does not provide.
19:24:50 [PaulC]
And since Relax NG does not give you a PSVI, how would XQuery work?
19:25:19 [TBray]
Some of us think the notion of PSVI is deeply harmful
19:25:33 [DanC]
PSVI harmful: quite.
19:25:36 [Ian]
PC: I think there should be one schema language. Why fragment the world on schema languages? There is some work (e.g., that schematron does) that can be done by combining xml schema and xml query.
19:25:47 [Ian]
PC: Relax NG doesn't give you PSVI.
19:26:00 [Ian]
PC: Some other W3C specs depend on the PSVI.
19:26:03 [Norm]
19:26:12 [TBray]
19:26:40 [Ian]
DO: If Relax NG produced a PSVI to what XML Schema produced, would you (PC) have the same objections? Is this a question of functionality or principle of one?
19:26:51 [Ian]
19:28:02 [Ian]
TBL: Propose we do not add to issues list right now.
19:28:03 [Roy]
I like alternatives
19:28:10 [Ian]
19:28:13 [Ian]
2.2 Findings in progress, architecture document (25min)
19:28:31 [Ian]
1. URIs, Addressability, and the use of GET (whenToUseGet-7 finding)
19:28:39 [Ian]
19:28:44 [Zakim]
19:28:44 [DanC]
$Author: duerst $. $Revision: 1.30 $
19:28:47 [Ian]
DC: Martin wrote the text himself. It's in the finding.
19:28:54 [Ian]
zakim, ??P8 is Stuart.
19:28:55 [Zakim]
+Stuart.; got it
19:29:09 [Ian]
Salve, Stuart.
19:29:17 [Ian]
Salut, David.
19:29:21 [TBray]
The thing that kicked off the Schema talk is
19:29:24 [Norm]
19:29:26 [DanC]
I 2nd Ian's proposal to adopt get7, along with MartinD's ammendment.
19:29:30 [Ian]
ack TBray
19:29:49 [Ian]
Withdrawn: ACTION CL Add concern regarding non-western characters to the POST scenario
19:29:55 [Ian]
# ACTION IJ 2002/05/20: Revise and publish whenToUseGet-7 finding
19:30:02 [Ian]
19:30:14 [Ian]
SW: I have not confirmed that it incorporates my comments.
19:30:27 [Ian]
SW: But I'll take it on trust that it has.
19:30:40 [Ian]
ACTION DO: Report to the XMLP task force that for operations where GET would be appropriate SOAP nodes should provide the ability to use GET
19:30:44 [DanC]
I'd prefer "8.2 Related work" were nuked, but I'm OK with leaving it as is.
19:30:54 [Ian]
I left it in for you.
19:30:56 [Ian]
I'm happy to nuke.
19:31:12 [Ian]
TB: We communicated our issues to XMLP people. They came back with a proposal.
19:31:22 [DanC]
we're evidently lumping "1. Response from XMLP WG " here under 2.2
19:31:33 [Ian]
DF message to
19:32:07 [Ian]
TB: Bullet points
19:32:42 [Ian]
1) I think that XMLP WG has, in scenarios, added examples of when GET is appropriate. They have asserted that in these cases, that should use GET. No information about shape of URI.
19:33:00 [Ian]
2) And that SOAP nodes "should do the right thing with this"
19:33:05 [TimBL]
No parameter encoding algorithm.
19:33:07 [Ian]
3) Primer was updated as well to reflect all of this.
19:33:44 [Ian]
TBL: In examples, is there indication algorithm to use?
19:33:53 [Ian]
DO: People commented about moving the GET binding earlier in primer.
19:33:55 [DanC]
yes? really? there's an algorithm? I got the distinct impression that no, there's no algorithm.
19:34:04 [Ian]
TB: There is no machinery for the parameter encoding.
19:34:13 [Ian]
DO: The TAG didn't ask for this.
19:34:23 [Ian]
TB: We made a proposal. But the TAG didn't say that the XMLP WG had to do a binding.
19:34:39 [Ian]
(last sentence was from DO: But the TAG didn't say that the XMLP WG had to do a binding.)
19:34:52 [Ian]
RF: The XMLP WG has satisfied this issue as much as the HTTP spec does this.
19:35:07 [Ian]
TB: They have done so not only "de jure" but with some measure of enthusiasm.
19:35:13 [Ian]
TBL: But there's a binding in the POST case.
19:35:28 [Ian]
TB: In the POST case, there is an envelope in both directions.
19:35:39 [Ian]
TB: With GET, they just say use HTTP.
19:35:52 [Ian]
RF: One of the fundamental principles of HTTP is that it doesn't define the syntax of the URI.
19:36:06 [Ian]
TBLP PEople will look to the SOAP spec to tell them how to encode.
19:36:31 [Ian]
DO: My best reading of this, is that the idea of developing machinery was thought to be fairly complicated and didn't really address the issue that GET should be used.
19:36:51 [Ian]
DO: Having arbitrary mappings between SOAP and HTTP-encoded parameters was not the main issue.
19:37:08 [TimBL]
19:37:43 [Ian]
SW: I would summarize slightly differently - the perception that SOAP is a framework for exchanging messages. If you are going to do the URI thing, you want to be able to do with any SOAP message, not just one that is a subset of SOAP (RPC with simple parameters). How would you do this in the general case of a SOAP message?
19:37:50 [DanC]
I have to stipulate that as long as their primer and such is clear on when to use GET, there's no longer an architectural problem with SOAP. I'm kinda bummed that we didn't get interoperable getStock("YHOO") while we're at it, but I'll live. Maybe we'll get that later.
19:38:17 [Ian]
TB: Is there a way to generate a URI from WSDL to do GET?
19:38:48 [Ian]
PC: This is one of the reason why the task force of the XMLP WG didn't want to do this; they thought that, e.g., wsdl 1.2 might describe how to do this.
19:38:58 [Ian]
DO: WSDL 1.1 does have a binding to HTTP GET and to POST.
19:39:14 [Ian]
TB: You can generate an appropriate URI from the WSDL?
19:40:13 [Ian]
[PC reads message from Noah M.]
19:40:38 [Ian]
TB: We want to avoid the case of google, for example, moving services out of GET space.
19:41:01 [Ian]
TB: Did the XMLP WG satisfy this scenario?
19:41:05 [Ian]
PC, DO: Yes.
19:41:21 [Ian]
TB: We asked them to make sure that things don't vanish out of URI space. They've done that.
19:41:58 [Ian]
TB: The second thing (perhaps more important) is the rhetoric that surrounds this. I think that we are well on the way towards the primer conveying to use GET for safe operations.
19:42:04 [Roy]
WSDL is a better place to contruct URI from and RPC interface
19:42:18 [Roy]
19:42:46 [PaulC]
Quotation from a message from Noah M: Henrik's suggestion is fine with me. I would also might add, and I think
19:42:47 [PaulC]
this is correct, that (1) the appropriate representation might depend on
19:42:47 [PaulC]
the URI scheme being used...for example, whether the URI scheme is
19:42:47 [PaulC]
hierarchical (http) vs. non (UUID) (2) that in many cases the appropriate
19:42:47 [PaulC]
mappings will be application dependent and (3) there will be many
19:42:47 [PaulC]
opportunities to integrate this with a description language such as WSDL,
19:42:50 [PaulC]
and those opportunitites are not available to usin the SOAP spec.
19:42:51 [PaulC]
In short: we aren't against there being standard co
19:42:59 [Ian]
DO: The XMLP WG did not provide a mapping between inbound SOAP request infoset and GET.
19:43:08 [Ian]
DO: Some people think this is an issue; others do not.
19:43:18 [PaulC]
... continuing quotation
19:43:19 [PaulC]
In short: we aren't against there being standard conventions applied in
19:43:20 [PaulC]
certain cases: we believe that the SOAP spec is not architecturally the
19:43:20 [PaulC]
right place to do it.
19:43:26 [TimBL]
19:43:26 [Roy]
I am satisfied with the XMLP work on addressing the issues.
19:44:18 [Ian]
RF: There are ways to encourage people to use HTTP GET when it's easier to use them. All that's necessary is that the protocol allows and supports it (rather than making it illegal).
19:44:39 [Ian]
TBL: I think the XMLP WG work has been great. But I have a concern that the gap is unforgeable.
19:45:20 [Ian]
TB: I think we should send a message to the WSDL WG to ask them to ensure that the machinery allows people to make available information in URI space.
19:45:22 [TimBL]
>1 issue here.
19:45:28 [Roy]
I agree with TB.
19:45:43 [Ian]
PC: There has already been email on that WG's mailing list. A message to the WG would be a good idea.
19:45:45 [Ian]
19:45:51 [Ian]
- We applaud the work of the XMLP WG.
19:46:28 [Ian]
TBL: The question remains - how will interoperability be addressed. The interface definition includes the marshalling rule (serializing data for remote operations).
19:47:02 [Ian]
TBL: I think we should note that this remains to be addressed, and hopes that it will be addressed. But that the interoperability achieved with POST has not yet been achieved with GET.
19:48:03 [TimBL]
ack TB
19:48:11 [Ian]
TB: I think TBL's question is reasonable - given that there is nothing normative said on how to do the mapping, there may be interoperability problems. But it's not clear to me to whom this concern should be addressed.
19:48:17 [TimBL]
q = do
19:48:22 [TimBL]
q= do
19:48:23 [Ian]
q+ Paul
19:48:30 [TimBL]
19:48:40 [Ian]
DO: Perhaps ask the Web Services Architecture Group?
19:48:55 [TimBL]
DO suggested tha they have done all they have to do.
19:49:11 [Roy]
19:49:19 [TimBL]
ack do paul timbl
19:49:25 [Ian]
PC: I'm not quite sure why we need to do this? We don't do this for other applications? There are people that use HTTP GET succesfully without them being told how to characterize their parameters.
19:50:16 [Ian]
TBL: The XMLP WG has done this for POST, and this is the format of the message to be sent.
19:50:38 [TimBL]
q + do
19:50:40 [TimBL]
q+ do
19:50:42 [Ian]
TBL: I don't see why the same thing would not be necessary when using GET.
19:50:45 [TimBL]
ack p
19:50:47 [TimBL]
ack t
19:51:02 [Roy]
I think that the notion that you get interoperability by specifying a POST syntax is completely bogus, for reasons discussed in my dissertation. Any GETable URI has built-in interoperability that far exceeds any SOAP envelope.
19:51:09 [Ian]
DC: Case in point - the Google had working stuff in URI space, SOAP specs came along, and google folks gave up being in URI space.
19:52:19 [Ian]
RF: How is it that you know that a given parameter in a URI reflects a stock quote?
19:52:28 [Ian]
TBL: There is an interface description.
19:53:07 [Ian]
TBL: You don't know what the syntax of the URI.
19:53:20 [Ian]
RF: I don't need a spec; I can see what millions of people are doing on the Web.
19:53:53 [Ian]
RF: How interfaces are specified in WSDL is another problem.
19:54:20 [DanC]
19:54:27 [Roy]
Data does not belong in the URI.
19:54:42 [Ian]
DO: I think that RF is right on here - SOAP specifies what to do in POST since there is no format otherwise; but there is a format for GET.
19:54:51 [Ian]
TBL: Are you referring to the format you use when you fill in an HTML form?
19:55:04 [DanC]
huh, roy? the string 'YHOO' shouldn't be part of the address for a stock quote for Yahoo?
19:55:15 [Roy]
Yes it should
19:55:20 [Ian]
TBL: The HTML spec says how to do this; the URL spec talks about "?" but not the syntax of what follows.
19:55:26 [DanC]
'YHOO' isn't data, then?
19:55:29 [Ian]
TBL: Are you relying on the HTML semantics?
19:55:41 [Roy]
YHOO is a name assigned by a naming authority (NASDQ).
19:55:46 [TimBL]
DO: People can go on using HTML form encoding.
19:56:03 [Ian]
DO: My second point - if the TAG had agreed that XMLP should do the binding, we should have told them.
19:56:05 [DanC]
I can't reconcile
19:56:18 [DanC]
I can't reconcile your claims, Roy. Is 'YHOO' data or not?
19:56:34 [Ian]
TB: DO and I proposed using the HTML form encoding.
19:56:45 [Roy]
It is an identifier (all bits are data -- you are being specious)
19:56:47 [TimBL]
q ?
19:57:10 [DanC]
I can't make any sense of "Data does not belong in the URI," then, Roy.
19:57:33 [Roy]
okay.. payload doesn't belong in the URI
19:57:33 [Ian]
TB: But I agree that the correct thing for the TAG to do at this point is to say that the XMLP WG did what we asked. I think it's reasonable to raise a further concern: Will the Web Services folks explain how we will get interoperability in the GET case?
19:58:36 [Ian]
SW: SOAP tells you how to form a message, but not what parameters to use. You can get this from WSDL.
19:59:00 [Ian]
TBL: To get a URL for a service is one thing, to get a URL for parameters is another thing (that might be complicated; e.g., with reg exps).
19:59:18 [Ian]
TB: I propose that:
19:59:37 [Ian]
1) We agree that the XMLP WG has done what we asked them to do.
19:59:43 [DanC]
we're already resolved on bray's 1st proposal there. TimBL called the question earlier.
19:59:47 [Ian]
2) We issue a query to the WSA WG expressing our concern.
20:00:27 [Ian]
DO: I suggest that we send to Web Services CG instead.
20:00:47 [Ian]
DC: I would prefer to make a guess and send to the arch wg
20:01:28 [Ian]
PC: I think the CG is the right place, due to weight of requests from TAG.
20:01:48 [Ian]
TBL: We could send back to the XMLP WG since they know the issue well, and ask them who should address this.
20:02:35 [Ian]
TBL: I note that there is disagreement on this call about the role of a CG.
20:02:48 [Ian]
DC: They work better by exception. I think that the WSA WG is a pretty good guess in this case.
20:03:35 [Ian]
Resolved: Send request to the WSA WG.
20:03:59 [Ian]
DC: I'm happy with whatever DO writes.
20:04:57 [Ian]
Action RF: Send thank you message to XMLP WG.
20:05:26 [Ian]
Action DC: Write up architecture concern.
20:05:32 [Ian]
(DO will champion in WSA WG).
20:05:45 [Ian]
DO: WSA WG has a ftf meeting in France starting Weds this week.
20:08:09 [Ian]
Resolved: Accept "URIs, Addressability, and the use of HTTP GET" Delete section 8.2. IJ may incorporate some of the related material up front.
20:08:13 [Ian]
20:08:18 [Ian]
Last modified: $Date: 2002/06/10 07:08:30 $ by $Author: duerst $. $Revision: 1.30 $
20:08:34 [Ian]
20:08:38 [Ian]
# Finding for formattingProperties-19
20:08:38 [Ian]
1. ACTION NW 2002/05/20: Draft a finding for formattingProperties-19; find out source of issue from CSS WG
20:08:48 [Ian]
NW - Pending.
20:09:02 [Ian]
20:09:14 [DanC]
on 3. lacks examples
20:09:23 [Ian]
20:09:23 [Ian]
20:09:23 [Ian]
# Internet Media Type registration, consistency of use
20:09:23 [Ian]
1. ACTION DC: research the bug in the svg diagram.
20:09:29 [Ian]
DC: I suggested losing the SVG diagram.
20:10:20 [Ian]
DC: I have not updated the diagram.
20:10:26 [Ian]
TB: I have not studied the diagram.
20:10:32 [Ian]
Proposal: Remove the SVG diagram.
20:11:05 [Ian]
DC: I did send some relevant mail, just before this meeting.
20:11:14 [Ian]
DC: I would like to hear from Martin first.
20:11:24 [Ian]
Action continued.
20:11:31 [Ian]
20:11:33 [Ian]
20:11:33 [Ian]
20:11:33 [Ian]
# QNames as Identifiers (qnameAsId-18)
20:11:33 [Ian]
1. Review draft finding from NW.
20:11:38 [Ian]
20:11:44 [Ian]
NW: I added some recommendations to the end.
20:11:52 [Ian]
NW: There has been some discussion. I could do another round of edits.
20:12:06 [Ian]
DC: I would have an easier time reviewing this if it started with an example.
20:12:24 [Ian]
TB: I agree with the finding. I suggest salting with examples.
20:12:35 [Norm]
20:12:36 [Ian]
NW: I have resorted to examples in email to expalin it.
20:12:50 [Ian]
[The TAG supports more examples and diagrams in the world!]
20:13:28 [Ian]
Action NW: Add examples to Qnames finding.
20:13:59 [Norm]
20:14:27 [Ian]
TBL: I think that we should identify holes in the architecture (e.g., frag ids).
20:15:57 [Ian]
Norm, one minor comment: In section 4, would bullet 4 be clearer as bullet 2?
20:16:45 [Ian]
DC: Related but separate issue: rdfmsQnameUriMapping-6
20:16:46 [Ian]
20:17:06 [Norm]
20:17:36 [Ian]
DC: Norm, please include reference to issue 6 in your finding.
20:17:52 [Ian]
NW: I will do that.
20:17:56 [Zakim]
20:18:27 [Ian]
TB: I had an action on rdfmsQnameUriMapping-6. I would like to note for the record that there was a lack of input on www-tag that this was an important issue.
20:18:47 [Ian]
TB: I do not observe the crowd brandishing their firebrands to take up this issue.
20:19:02 [Ian]
TB: I suggest we close issue 6.
20:19:11 [Ian]
DC: I don't want to do that without TBL here since I think he cares.
20:19:19 [Ian]
[DC starts chairing]
20:19:49 [Ian]
20:20:15 [Ian]
Arch document.
20:20:18 [Ian]
TB: I like the terse style.
20:20:26 [Ian]
20:20:27 [DanC]
recent draft:
20:20:47 [Ian]
TB: If we don't have any material for chapters 3 and 4, maybe we should delete them.
20:20:55 [Ian]
DC: I don't think that will be the case.
20:21:22 [Ian]
TB: Dictionary entries are created by examination of usage instances. They stack them and build a TOC.
20:22:01 [Ian]
DO: I like the terseness. I think it gives us a basis for reference.
20:22:11 [Ian]
TB: Sprinkle the whole thing with examples.
20:22:23 [Ian]
DO: Do you see examples in the arch document or a primer?
20:22:25 [Ian]
TB: Inline.
20:22:49 [Zakim]
20:22:51 [Ian]
TB: Use a good example to replace 3 paras of prose.
20:23:09 [Ian]
DO: I have some concerns, but ok to move forward in current direction.
20:23:30 [Ian]
ACTION TBL: Negotiate more of IJ time for arch doc
20:23:30 [Ian]
20:24:07 [DanC]
if anyone wants the meeting to go longer than xx:30, pls say so now.
20:24:15 [Ian]
TBL: We discussed at the AB call earlier today. IJ will do less work in AB. But there are ongoing questions about Process Document editing. I'd like to wind down the amount of time the AB puts into the Process Document.
20:24:17 [PaulC]
I'm sorry I interupted. I thought Dan C was asking the question of Tim Bray and I thought I needed more background
20:25:02 [Ian]
DO: What about asking the AC opinion on priorities?
20:25:15 [Ian]
TBL: We have been careful in the past not to ask the AC too much (since they get a lot of mail).
20:25:34 [PaulC]
Why not ask people running for AB if they are willing to take on this editorial task?
20:26:26 [PaulC]
20:26:34 [DanC]
Ian: what's still on my plate for this summer: finishing process document, editing WAI UA.
20:26:55 [Ian]
IJ: Now that arch document is moving forward, should be easier to manage.
20:27:35 [Roy]
I think we should accidentally unsubscribe Ian from the AC list.
20:27:40 [Norm]
20:28:36 [Ian]
PC: I think this is a w3m decision.
20:28:36 [Ian]
PC: Can W3M take this up and report back?
20:28:45 [Ian]
So TBL's action is now to take to w3m and report back to TAG.
20:29:01 [DanC]
with the exception of 1XMLP stuff, I propose to postpone "2.3 Priority issues (50min)" and adjourn.
20:29:05 [Ian]
20:29:09 [Ian]
Next week's agenda?
20:29:44 [Ian]
# RFC3023Charset-21
20:29:44 [Ian]
* ACTION CL 2002/6/03: Write up the issue in the next day or so.
20:29:44 [Ian]
20:29:46 [Ian]
Not done eyt.
20:29:55 [Ian]
- charmod-Review-17 ball not in our court.
20:30:03 [Ian]
TB: I'd like to invest some of our time in the arch document.
20:31:10 [Ian]
DO: I'd like to look at before we announce to www-tag.
20:31:47 [Ian]
RF: I don't want to deal with the email rush on the document yet.
20:32:25 [Zakim]
20:32:26 [DanC]
20:32:33 [TBray]
I'm outta here bye
20:32:38 [Zakim]
20:32:40 [Zakim]
20:36:58 [Zakim]
20:39:28 [Zakim]
20:39:31 [Zakim]
20:39:32 [Zakim]
20:45:38 [Zakim]
20:45:38 [Zakim]
20:45:38 [Zakim]
TAG_Weekly()2:30PM has ended
20:52:03 [Ian]
RRSAgenda, stop
20:52:10 [Ian]
RRSAgent, stop