IRC log of tagmem on 2003-09-29

Timestamps are in UTC.

18:58:14 [RRSAgent]
RRSAgent has joined #tagmem
18:58:26 [timbl]
timbl has joined #tagmem
18:59:57 [Ian]
zakim, this is TAG
18:59:57 [Zakim]
ok, Ian
19:00:03 [Norm]
Zakim, who's here?
19:00:03 [Zakim]
On the phone I see Norm
19:00:04 [Zakim]
On IRC I see timbl, RRSAgent, Zakim, Stuart, paulc, DanC, Norm, Ian
19:00:12 [Ian]
zakim, call Ian-BOS
19:00:12 [Zakim]
ok, Ian; the call is being made
19:00:14 [Zakim]
19:01:10 [Zakim]
19:01:11 [Zakim]
19:01:31 [TBray]
TBray has joined #tagmem
19:01:41 [Zakim]
19:01:48 [Zakim]
19:02:07 [Ian]
zakim, ??P3 is Stuart
19:02:07 [Zakim]
+Stuart; got it
19:02:19 [Zakim]
19:02:20 [Zakim]
19:02:30 [Norm]
Zakim, tim_bray is tbray
19:02:30 [Zakim]
+tbray; got it
19:02:47 [Stuart]
zakim, who is here?
19:02:47 [Zakim]
On the phone I see Norm, Ian, TimBL, DOrchard, Stuart, tbray
19:02:48 [Zakim]
On IRC I see TBray, timbl, RRSAgent, Zakim, Stuart, paulc, DanC, Norm, Ian
19:02:50 [Zakim]
19:03:07 [Ian]
Regrets: CL
19:03:47 [Ian]
Present: TBL, SW, PC, NW, IJ, DC, DO
19:03:49 [Ian]
Missing: RF
19:04:02 [Ian]
Present: TB
19:04:02 [Ian]
19:04:34 [Ian]
Accept the minutes of the 15 Sep teleconf?
19:04:40 [Ian]
19:05:00 [Ian]
Resolved: Accepted
19:05:42 [paulc]
Joining telcon.
19:05:43 [Ian]
19:05:51 [Ian]
19:05:53 [Zakim]
19:06:01 [Ian]
zakim, ??P5 is PaUl
19:06:01 [Zakim]
+PaUl; got it
19:06:54 [Ian]
DC: What happened to RDDL on agenda?
19:07:10 [Ian]
PC: I haven't delivered my action item. I hope to have something done this week.
19:07:29 [Ian]
TBray: I'm still working on RDDL Note; not yet done.
19:07:39 [Ian]
19:07:48 [Ian]
1.1 TAG participation in Tech Plenary 2004 (1-5 March)
19:08:17 [DaveO]
DaveO has joined #tagmem
19:08:43 [paulc]
19:08:47 [DaveO]
19:08:49 [paulc]
19:08:56 [Ian]
Should we meet? Should we interact with other groups?
19:09:05 [Ian]
Meeting is in south of France.
19:09:08 [Ian]
ack DanC
19:09:08 [Zakim]
DanC, you wanted to speak in favor of meeting
19:09:16 [Ian]
DC: Yes, please, let's meet.
19:09:20 [Ian]
ack DaveO
19:09:31 [Ian]
DO: We could meet with WSDL WG to talk about issue 37
19:09:36 [DanC]
meeting with WSDL folks seems cool.
19:10:03 [Ian]
DO: Yes, let's meet too.
19:10:07 [Ian]
PC: I'm against meeting then.
19:10:10 [Ian]
ack paulc
19:10:28 [Ian]
PC: I agree that we should meet then, but I'll be busy for at least two days since Chair.
19:11:27 [Ian]
PC: One of my groups may even meet on the weekend.
19:12:23 [Ian]
PC: Also lots of last call docs will be around; likely to be heavily booked.
19:12:28 [Ian]
NW: I'm also overbooked during that time.
19:12:33 [DaveO]
what is our quorum for meeting?
19:12:41 [Ian]
19:13:14 [Ian]
PC: I'd prefer to do what we did last year - to meet at an alternate site before the TP so that people running for election could either be notified during the ballot period when the TAG would be meeting.
19:13:17 [DanC]
I prefer to have consensus to meet.
19:13:22 [DanC]
I'd rather not meet over anybody's objection
19:13:36 [DanC]
regrets are one thing. objections are another.
19:14:37 [Ian]
If no TAG teleconf, who won't come to France: TB, SW
19:14:58 [Ian]
Or rather, at risk: DO, SW
19:15:45 [Norm]
Norm has joined #tagmem
19:15:46 [Ian]
SW: Then I will let TP organizers know that the TAG does not expect to hold a ftf meeting during that time.
19:16:13 [Ian]
SW: However, I'd like to discuss (over the next couple of weeks) what the TAG's contributions could be to the tech plenary day.
19:16:15 [paulc]
The result is that I recommend that we group the WGs of the XML and WS Activities this way:
19:16:16 [paulc]
A: WS Architecture, XML Core, XML Protocol, XML Schema
19:16:16 [paulc]
B: WS Choreography, WS Description, XML Query, XSL
19:16:16 [paulc]
with group A meeting Monday and Tuesday and group B Thursday and Friday, or vice versa.
19:16:42 [Ian]
DO: I would much rather meet in France with a subset of the TAG (large majority) than to have more trips.
19:16:58 [Zakim]
19:17:03 [paulc]
The above is the proposed internal schedule for WGs which is member-only info and is only a draft.
19:17:42 [paulc]
19:17:47 [Norm]
For the record, I don't object to meeting in Cannes. It'll be awkward if we do, but that's fair.
19:18:12 [Ian]
PC: I'd like to encourage the TAG to participate in the organization of the tech plenary itself.
19:18:36 [Ian]
PC: I won't be on the organization committee for the TP this year.
19:19:52 [Ian]
NW: I don't object to TAG meeting ftf during that week. But I'm booked solid for now.
19:20:35 [DaveO]
One of the reasons I wanted to meet was because WSDL will be there and we have an issue that would probably be helped by meeting together for a few hours
19:21:29 [Ian]
SW: I think last year more people had more conflicting meeting schedules last year.
19:21:37 [Ian]
RF: This would be the first meeting after the election, right?
19:21:38 [Ian]
SW: Yes.
19:21:58 [Ian]
RF: The idea was to have departing participants also participate in transitional meeting.
19:22:53 [Ian]
SW: I therefore plan to set expectations that we'd like to meet, but some hurdles.
19:23:05 [Ian]
PC: We can postpone until our ftf meeting...
19:23:09 [Ian]
1.2 TAG highlights from previous six months (for AC meeting)
19:23:26 [Ian]
See previous highlights (Member-only).
19:23:33 [Ian]
19:24:39 [Ian]
Action SW: Draft summary based on monthly reports for TAG.
19:25:00 [Ian]
1.3 Bristol FTF Agenda
19:25:21 [Ian]
SW: I've not yet done a detailed agenda page. But the meeting will focus on what's required to go to last call.
19:25:45 [Ian]
SW: If we get done early enough, we'll work on findings and have time to do todos.
19:26:13 [Ian]
TBL: I hope to be able to join remotely for part of the meeting.
19:26:31 [Ian]
SW: We expect to have audio; I'll check about video this week.
19:26:43 [Ian]
TBL: I'd be willing to visit an HP facility in Cambridge (MA).
19:27:21 [Ian]
[DC has sent regrets]
19:27:36 [Stuart]
19:28:27 [paulc]
Thanks to SW for all the meeting logistical arrangements.
19:28:36 [paulc]
19:28:41 [DanC]
ack danc
19:28:41 [Zakim]
DanC, you wanted to ask where issue namespaceDocument-8 is w.r.t. critical-path for last call and ftf agenda
19:29:00 [Ian]
DC: Was namespace-8 critical path for last call?
19:29:12 [Ian]
TBray: PC is creating finding + sound bite for web arch.
19:30:07 [Ian]
DC: If I can't read materials now, I may argue for not making any decisions on this issue at the face-to-face meeting.
19:30:24 [Ian]
19:31:03 [Ian]
DC: My position on issue 8 is that if we do nothing, that's acceptable. There are a lot of somethings that are not ok to me.
19:31:20 [Ian]
DC: If we have some spec that doesn't have a clear mapping to RDF, that would be a step backwards.
19:31:21 [Ian]
19:32:25 [Ian]
SW: Look forward to seeing those in England next week.
19:32:28 [Ian]
2.1 Architecture Document
19:32:59 [Ian]
19:33:06 [Ian]
SW: Can we approve TR page draft today?
19:33:41 [Ian]
19:34:08 [TBray]
grr you don't need both quotes and <code> for URIs
19:34:13 [TBray]
in stories
19:34:16 [DanC]
quite, TBray
19:35:10 [Ian]
19:35:18 [Ian]
Abstract rewrite
19:36:18 [Ian]
DC: Abstract too long, but nothing critical IMO.
19:37:04 [Ian]
TBray: I'm ok with the abstract (just a couple of stylistic nits)
19:37:42 [DanC]
abstract is too long for my tastes, but I don't see anything technically incorrect
19:38:05 [TBray]
words "to be" after the colon in 3rd para of abstract are grammatically strained, will suggest something smoother
19:38:21 [Ian]
IJ: I think people would like something more concrete about what info space and info system are.
19:38:37 [Ian]
DC: I have a mild pref for talking about info space over info system.
19:38:45 [DanC]
... used to not care
19:39:14 [Ian]
TBL: I think we're going to have to make a bigger distinction between HTTP Web and other systems.
19:40:03 [Ian]
19:40:37 [DanC]
19:41:13 [Ian]
(1 is closed I think)
19:42:28 [Ian]
#2: SW - I think that this is a linguistic misunderstanding, should be "per URI scheme"
19:42:39 [TBray]
The endnote is wrong
19:43:41 [Ian]
DC: TOo much detail - "The browser uses its configuration2 to determine how to locate the identified information, which might be via a cache of prior retrieval actions, by contacting an intermediary (e.g., a proxy server), or by direct access to the server identified by the URI."
19:43:47 [Ian]
SW: I propose to delete footnote 2.
19:43:48 [Ian]
TBray: yes.
19:44:07 [Ian]
DC: No need to talk about browser config in the intro.
19:44:47 [Ian]
RF: I'm ok with not talking about browser config in the intro. I don't want to give the impression that the browser makes some decisions, dont' just look at URI spec (e.g., can look at cache).
19:44:48 [DanC]
hmm... yeah... where to talk about browser config and caches? not the intro, but ... hmm.
19:45:38 [Ian]
SW: The right place for this is in the interactions section.
19:45:49 [Ian]
SW: The expansion should be in that section.
19:45:51 [Ian]
DC: Sounds plausible.
19:45:55 [Ian]
RF: Sure.
19:47:06 [Ian]
DC: I don't want to queue up a bunch of stuff before publishing.
19:47:49 [Ian]
#3) Proposed to add reference to RFC2396 in endnote 3.
19:48:35 [Ian]
#4) Cause/effect backwards in describing "link".
19:48:48 [Zakim]
19:49:13 [Stuart]
19:49:23 [Ian]
"When a representation of one resource refers to another resource with a URI, a link is formed between the two resources."
19:49:33 [Zakim]
19:50:08 [Ian]
SW: That suggests that the presence of a reference that causes the link to form, as opposed to "There exists a link, therefore there's a URI ref in a representation."
19:50:13 [Ian]
RF: I agree with Stuart.
19:50:44 [Ian]
RF: But there's an issue if you have several representations, some of which have links and some of which don't.
19:50:55 [Ian]
RF: I don't believe strongly in either view.
19:51:11 [Ian]
TBray: I'm much happier saying that the link is formed by presence of URI ref.
19:51:29 [Zakim]
19:51:33 [Zakim]
19:51:47 [Ian]
TBL: Rather : "When there is a URI ref in a representation, we call that a link."
19:52:13 [Ian]
(TBL: "we OFTEN call that a link")
19:52:17 [DaveO]
I'm happy with SW's or TBL's wording. I like the coupling of links with representations rather than resources.
19:52:37 [Ian]
TBL: In the use of the Web for global hypertext, the use of a URI ref in a representation is called a link.
19:52:45 [Ian]
DC: So this shouldn't be introduced in this section...
19:53:09 [Ian]
TBL: I'm ok to start off with talking about most popular case rather than an abstration.
19:53:32 [Ian]
DC: You don't get network effects without any links.
19:53:53 [Ian]
19:54:05 [TBray]
19:54:27 [DaveO]
19:54:43 [Ian]
RF: The link is one directional, but the relationship is bi-directional.
19:55:04 [TBray]
19:55:57 [DanC]
changing "formed" to "represented" might help
19:56:12 [TBray]
Agree with DanC
19:56:16 [DanC]
"formed" has a before/after feel to it. odd.
19:56:19 [timbl]
agree with danc
19:56:22 [Stuart]
Yes that would work for me
19:56:48 [Ian]
DC: "This represents a link between the two resources."
19:57:00 [TBray]
19:57:05 [Ian]
19:57:14 [Roy]
Roy has joined #tagmem
19:58:16 [TBray]
q+ to say NO
19:58:26 [DanC]
When a representation of one resource refers to another resource with a URI reference, this represents a link between the two resources."
19:58:47 [Ian]
IJ: What about s/URI/URI ref here?
19:58:50 [Ian]
DC: Could work.
19:58:52 [Ian]
TBray: I disagree.
19:59:01 [DanC]
When a representation of one resource refers to another resource with a URI, this represents a link between the two resources.
19:59:08 [Ian]
TBray: The representation *logically* includes a URI.
19:59:16 [Stuart]
19:59:21 [DaveO]
19:59:43 [TBray]
19:59:52 [Ian]
#5) 2.4.1 Secondary Resources...
20:00:23 [TBray]
#5 in
20:00:42 [Ian]
IJ: I need to make sure s/agent/component in 2.4.1
20:01:20 [TBray]
20:01:22 [DanC]
s/the/a/ in "the URI for the secondary resource"
20:01:32 [Ian]
SW: This implies that you need to know the media type.
20:01:38 [Ian]
DC: No, it doesn't. It says "if you know it."
20:02:00 [Ian]
Text in question in 26 Sep draft:
20:02:06 [Ian]
"The syntax and semantics of fragment identifiers are defined by the set of representations that might result from a retrieval action on the primary resource. Fragment identifier semantics differ among format specifications. The presence of a fragment identifier in a URI does not imply that a retrieval action will take place."
20:02:40 [Ian]
TB rant: I've flagged this in a bunch of drafts. I think that the first sentence is either incomprehensible or wrong.
20:03:01 [Ian]
TBray: I think that the syntax and semantics are defined by the relevant documentation, and interpreted in the context of the representation that you get.
20:03:08 [timbl]
20:03:12 [Ian]
ack TBray
20:03:17 [Ian]
ack timbl
20:03:33 [Roy]
defined --> determined ?
20:03:40 [Ian]
TBL: I think the first sentence is a bit perverse for the following reason - Depending by the format ....
20:04:21 [Ian]
TBL: The set of things that the frag id could identify are defined by the set of different representations you get.
20:04:33 [Ian]
TBL: On the other hand, if the semantics are different, then we have a bug.
20:04:45 [Stuart]
20:05:23 [Roy]
20:05:34 [Roy]
ack DanC
20:05:34 [Zakim]
DanC, you wanted to agree that 2.4.1 is not right. can we just make an editor's note and move on? our target is a decision to publish, not substantive technical discussion, yes?
20:06:03 [Ian]
TBL: I would support deleting the first sentence and leaving and editor's note in its place.
20:06:08 [DanC]
+1 delete "The syntax and semantics of fragment identifiers are ..."
20:06:18 [Ian]
TBray: +1 to delete
20:06:21 [Roy]
I would just change "defined" to "determined"
20:06:46 [Ian]
TBL: I don't think you solve the problem that way.
20:07:04 [Ian]
TBL: There's an implication that one representation suffices; you need to know a set.
20:07:09 [Ian]
RF: You do need to know the set.
20:07:18 [Ian]
TBL: No, I only need to know the one I got.
20:07:26 [Ian]
TBray: That's right.
20:07:39 [Ian]
RF: In that context, maybe. But in the RDF context, you need to know the set of references.
20:08:18 [Ian]
TBray: The architectural intent is that the semantic of the identifier be consistent. But in the microscale is that the interpretation depends on the representation you get.
20:09:28 [Ian]
#6) "For schemes that do specify the use of fragment identifiers..."
20:09:32 [Ian]
People are satisfied with deleted.
20:09:45 [Ian]
#7) Good Practice Note: Content Negotiation With Fragments.
20:10:31 [Ian]
IJ: I didn't change back to previous draft.
20:10:48 [Ian]
"Good practice: Content negotiation with fragments"
20:11:43 [Ian]
s/and who use/who use/
20:11:58 [Ian]
DC: I second the point made by Larry in email that "authorities" is ....
20:12:15 [Ian]
DC: Talking about "the owner" of a URI ....
20:12:25 [Ian]
DC: the good practice note is not talking about HTTP space.
20:12:30 [Ian]
20:12:40 [Roy]
ack Roy
20:12:45 [DanC]
ack danc
20:12:45 [Zakim]
DanC, you wanted to note that "Authorities responsible for minting a URI" is too narrow
20:12:55 [Roy]
20:13:25 [Ian]
DC: You can narrow the principle to HTTP URIs, but as stated, not narrowed to HTTP space.
20:14:17 [Ian]
TBL: In practice, I haven't seen people use fragids with msg ids.
20:14:25 [Ian]
RF: I disagree with LM's comments but for different reasons.
20:14:29 [Roy]
20:14:38 [timbl]
In practice we are talking largely about HTTP.
20:14:40 [Ian]
#8) 2.5.2
20:14:55 [Ian]
Leave as is.
20:16:17 [Ian]
Section 2.6: Two paras creating discomfort:
20:16:35 [Ian]
- Moby Dick.
20:17:26 [Ian]
- Ambiguity example.
20:17:50 [Ian]
SW: Ambiguity example closely tied to linguistic ambiguity.
20:18:03 [Ian]
SW: Mark this para with editor's note as needing attention.
20:18:38 [Ian]
TBL: I don't like the Moby Dick example since it's criticizing an English statement.
20:18:50 [Ian]
#10) 4.5 Binary and Textual Data Formats
20:19:28 [Ian]
SW: make forward reference more narrow to 4.10.6 (not all of 4.10)
20:19:54 [Ian]
#11) Present table of notes after TOC as three lists.
20:19:55 [Ian]
20:20:07 [Ian]
#12) Choose a different icon (smaller) to indicate story. Roy seems to concur.
20:21:52 [Ian]
[Back on 4.4] Text is defined as being sequence of chars, not something that is marked "text/*".
20:22:35 [Ian]
TBL: Distinction between application is used to mark up text and applications where XML is used to mark up any kind of data.
20:23:32 [Ian]
TBL: This connects to "text/". The argument for using "text/" is that when there's a lot of text content, show people the text content. Not necessarily the case for apps where most of the data is not text.
20:24:02 [Ian]
TBray: I've not seen discussion about changing the definition of things you can do in the "text" (MIME) tree.
20:24:40 [DanC]
(timbl is part of multiple we's)
20:24:49 [Ian]
TBL: We had already asked them NOT to change 3023 since it was to be included in a W3C spec.
20:25:02 [Ian]
TBray: And I got my ear chewed off when I forgot.
20:25:53 [Ian]
TBray: We need to make up our minds - do we try to fix 3023 or not?
20:26:21 [Ian]
20:26:25 [Ian]
Any objections to publishing?
20:26:27 [Roy]
It's better than the last one, +1
20:26:47 [Ian]
Resolved: Request publication of TR draft.
20:26:55 [Ian]
IJ: I will make conservative edits before requesting publication.
20:27:09 [Ian]
Approximately 1 October.
20:27:14 [Ian]
(IJ estimates)
20:27:58 [Ian]
DC: There's an IETF/W3C meeting in 10 days. I'd like to spend 10 minutes on RFC3023
20:28:47 [Roy]
Leave charset on text/xml; remove charset from application/*xml
20:28:49 [Ian]
TBray: 3023 has been out there for a while. I think that fixing it at this point is better than not fixing it. There seems to be rough consensus about what needs to be done: deprecate "text/" for XML formats.
20:29:11 [Ian]
ack DanC
20:29:12 [timbl]
20:29:28 [Ian]
DC: My preference is to have this come out of a W3C spec for an XML Mime type.
20:29:46 [Ian]
NW: I think the Core WG is trying to wrap up the blueberry spec.
20:30:13 [Ian]
DC: The MIME registry currently points to an IETF spec; would be more straightforward if it pointed to a W3C Rec.
20:31:02 [Ian]
TBL: Suboptimal to have the MIME registry point to two specs at two orgs, which undergo different processes.
20:31:27 [Ian]
TBray: Can we have a chat with editors of 3023.
20:31:29 [Ian]
DC: Sounds good.
20:31:41 [Ian]
TBL: I'd like to make changes in a W3C document.
20:32:01 [TBray]
20:32:24 [Zakim]
20:32:25 [Ian]
20:32:29 [Ian]
RRSAgent, stop