IRC log of tagmem on 2003-01-06

Timestamps are in UTC.

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