IRC log of #tagmem on 2002-02-18

Timestamps are in US East Coast.

<ian_> Action item review

<ian_> 1. Summarize different approaches currently used for mapping URIs to media types.

<ian_> Subsumed.

<Zakim> +DanC

<ian_> Agenda:

<ian_> a) Action item reviwe

<ian_> b) Issues described as "meta" in www-tag.

<DanC> agenda += Admin: action review

<Zakim> +DOrchard

<DanC> agenda+ Admin: action review

* Zakim notes agendum 1 added

<ian_> RF: Maintain "Assigned to Assigned at Status Summarize different approaches currently used for mapping URIs to media types."

<DanC> "meta" in www-tag? or in

<ian_> TB: Is Eastlake's the only proposal in play?

<ian_> RF: People posted a couple to the mailing list.

<Zakim> + +1.604.932.aaaa

<ian_> SW: See Graham Klyne's email.

<TimBL> Zakim, who is here?

<Zakim> I see TimBL, Stuart, N.Walsh, TBray, Roy, Ian, DanC, DOrchard, +1.604.932.aaaa

<DanC> Zakim, PaulC just joined

<Zakim> I don't understand 'PaulC just joined', DanC. Try /msg Zakim help

<DanC> Zakim, PaulC just arrived

<TimBL> Zakim, +1.604.932.aaaa is PaulC

<Zakim> I don't understand 'PaulC just arrived', DanC. Try /msg Zakim help

<Zakim> +PaulC; got it

<ian_> "Summarize TAG findings on using URIs: (a) use URIs when naming in context of Web (2) should be able to follow URI to explanatory material (3) software is not required to follow a URI when processing it"

<ian_> PC: I sent a note that I wouldn't do this until it settled down.

<ian_> DC: How do we make progress?

--> Dave ( has joined #tagmem

<ian_> PC: I'd prefer to postpone for now.

<ian_> ...early findings from ftf were mooted by discussions two hours later.

<ian_> q

<ian_> +q

* Zakim wonders where q is

<ian_> q+

* Zakim sees Ian_ on the speaker queue

<Dave> ping

<Norm> pong, Dave

<-- Dave ( has left #tagmem (Dave)

--> Dave ( has joined #tagmem

<Dave> ping

<Norm> pong, Dave

<ian_> PC: Can the WG confirm the three proposed points: "Summarize TAG findings on using URIs: (a) use URIs when naming in context of Web (2) should be able to follow URI to explanatory material (3) software is not required to follow a URI when processing it"

<ian_> TB: We have some agnst - I don't want the entire world to disappear behind an @@ document.

* ian_ missed format TB mentioned.

<ian_> Conclusion: PC's action postponed.

<DanC> @@=XSD, i.e. W3C XML Schema

<Norm> ian_: he said XSD

<ian_> Done: Ping Misha and Martin and ask them to copy their concerns to the (XML?) IG so we can quote it.

<ian_> Done: Write up that the TAG approves of IETF draft from Don Eastlake with "http:" instead of "content-type:".

<ian_> SW: I also raised discussion points:

<Norm> URI:

<ian_> TBL: Please make this finding public.

<ian_> Action SW: Send the same information to the www-tag. Indicate draft status.


<ian_> ----------------------------

<ian_> "What is the significance of a namespace?

<ian_> "

<ian_> "How do we expect languages to be defined?"

<ian_> "What about the idea of resources that are both human- and

<ian_> machine-readable?

<ian_> "

<ian_> TBL: Need to write down what we believe and why we believe it.

<TimBray> BTW, I have a new headset... plaease complain if I'm staticy or inaudible

<ian_> TBL: We can't have a nihlistic void behind this. The Web does have certain assumptions behind it. We don't have a carte blanche to rephilosophize everything.

* ian_ notes that TB is a little quiet.

<ian_> TB: TBL, can you be more explicit about possible outcomes?

<ian_> TBL: I think that we largely agree on matters; differences are in how we express ourselves.

<DanC> I read and I was fine until point 14. The premise of thesis 14 is that schemas are all about syntax. phooey

<ian_> TBL: ...but if the TAG were not to be able to make any statement about messages having "meaning" (or some other word), i.e., no bits have any meaning, I would not be happy.

<ian_> TB: Let's take that as a strawman.

<ian_> "Architectural Themes on Namespaces and Namespace Documents" by TB


<DanC> actually, I take issue with thesis 13 too; when you pick a format for the namespace document, you're necessarily going to prefer certain applications (e.g. web browsing) than others.

* TimBL opens the floor using Zakim's queue

<TimBL> ack DanC

* Zakim sees Ian_ on the speaker queue

<ian_> DC: Re 14: Namespace documents should not be schemas. This is a tenuous fit for RDF Schema. I don't think of schemas as simply constraining syntax.

<Dave> +1

* Zakim wonders where 1 is

<Dave> argh

<ian_> DC: ...RDF schemas are usually about licensing inferences.

<Dave> q +1

<ian_> PC: XML Schemas tell you how to validate. That's it.

<ian_> DC: You can't put anything in appinfo about what terms mean?

<ian_> PC: Yes, you can do that, but that's not part of the xml schema spec.

<ian_> TBL: I think we have a communications issue here. "Schema" being used to describe syntactic constraints only, while DC using term to include some semantic info as well.

<ian_> TBL: Can people agree to: "Unreasonable to limit descriptions to only syntactic constraints."

<ian_> ...are you agreeing that namespace not only be coupled to a syntactic thing?

<ian_> DC: I'd buy that.

<ian_> Proposed:

<TimBL> q?

* Zakim sees Ian_ on the speaker queue

<ian_> q-

* Zakim sees no one on the speaker queue

<Dave> q+

* Zakim sees Dave on the speaker queue

<TimBL> ack Ian

* Zakim sees Dave on the speaker queue

<TimBL> ack Dave

<ian_> TB: Heads-up - world thinks it knows what schemas are.

* Zakim sees no one on the speaker queue

<TimBL> Zakim, who is here?

<Zakim> I see TimBL, Stuart, N.Walsh, TBray, Roy, Ian, DanC, DOrchard, PaulC

<DanC> q+

* Zakim sees DanC on the speaker queue

<ian_> DO: I put forth that the w3c/tag adopt that a schema puts syntactic constraints. Don't extend definition of schema beyond what general public thinks it means.

<ian_> TBL: RDF schema is on the boundary.

<ian_> ....people are writing DAML schemas that contain property values that allow you do inferences.

<TimBL> q?

* Zakim sees DanC on the speaker queue

<TimBL> ack DanC

* Zakim sees no one on the speaker queue

<ian_> DC: If schemas are about syntax only, I'm happy to rename RDF schemas. But I'm not convinced that all schemas are only about syntax. Take invoices, for example.

<ian_> TB: The machine readable part is only about syntax, isn't it?

<Roy> TB wrote "constraints on the syntax, structure, and content of resources." I take that to mean semantics of what is in the content.

<ian_> PC: You don't know what the recipient will do with the data.

<Norm> q+

* Zakim sees Norm on the speaker queue

<ian_> DC: I don't think that's true. People do have expectations.

<TimBray> q+

* Zakim sees Norm, TimBray on the speaker queue

<ian_> DC: ...whatever you put in appinfo tells you something about your vocabular.

<ian_> PC:

<ian_> 1) No standard way to do this in appinfo

<ian_> 2) This is work for next XML Schema WG.

<ian_> DC: I think people are already doing this.

<ian_> doesn't have to be standardized to be working.

<TimBL> Charles Goldfarb's view is that the document type defined the meaning of tags as well as the syntactic constraints

<TimBL> q+

* Zakim sees Norm, TimBray, TimBL on the speaker queue

* ian_ forgot to invite RRSAGent.

<TimBray> SGML also holds that the "DTD" includes the human-readable & other accompanying docs

--> RRSAgent ( has joined #tagmem

Timestamps are in UTC.

16:00:17 [ian_]
NW: I have been thinking about what "meaning" mime type + bits has: There's more context than we currently express with mime types + bits. If you send me a purchase order, I will drop on the floor. I have no context with you to process invoices.
16:00:32 [ian_]
NW: The schema (or Schema) + bits + media type don't give you anything.
16:00:37 [DanC]
16:00:49 [Stuart]
+1 wrt Norm
16:01:09 [ian_]
TB: I agree with NW - we can't yet just process messages for what they are.
16:01:53 [ian_]
TB: On semantic information in schemas - in most cases, comments hold the status of comments. I think that these are red herrings in general. I would not react to non-standardized appinfo information. I would to previously engineered agreements between us, or on standardized terms.
16:01:55 [DanC]
So if I publish a "this is a price quote schema; documents that use this schema are price quotes" at XYZ, then I publish another document that refers to XYZ and points to XYZ, I'm not accountable for the price quote? I don't have to sell you the goods at the quoted price?
16:02:15 [DanC]
refers to and conforms to
16:02:43 [ian_]
TBL: NW is absolutely right. Communication only happens between two parties when there is agreement about how to handle documents.
16:03:02 [TimBray]
I think it's only binding because you've made a public *human-readable* statement
16:03:25 [ian_]
..our arrangement may be by phone, for example, with lots of context behind the word "sell", for example.
16:03:32 [ian_]
(previous statement was by TBL)
16:04:04 [ian_]
TBL: More context may be a given country's laws, for example. Two parties are "deemed to understand", for example.
16:04:09 [DanC]
TimBray, suppose I write, in natural language, a human-readable spec for an assertion language, then I write the quote schema in that assertion language, then I publish the quote?
16:05:06 [ian_]
TBL: What we do with the Web and Web protocols, we say that when you open a connection at port 80 (for example), you agree to take on certain responsibilities. Like opening a bank account implies agreement to a lot of contractual provisions.
16:05:38 [ian_]
TBL: The Web works on a lot of common assumptions. When you use GET, you are saying "I will understand the bits in this context."
16:06:34 [ian_]
TBL: So I agree with NW philosophically, but I think that there are commonly understood terms. Does that provide an adequate bridge between philosophy and meaning of standardized bits (e.g., for invoices)?
16:07:00 [ian_]
TBL: And thus you would be justified in interpreting a well-defined invoice as an invoice, and not as something else.
16:07:39 [ian_]
NW: Yes, if I've done something to indicate that I will accept purchase orders from you. I'm not sure that the fact that you've send me (unasked for) a document of a particular type, that I'm responsible for any particular action.
16:07:48 [TimBL]
16:07:50 [ian_]
TBL: I'm not saying you're responsible for a particular action...
16:07:55 [Norm]
16:07:57 [TimBL]
ack Norm
16:08:02 [TimBL]
ack TimBL
16:08:06 [TimBL]
ack TimBray
16:08:07 [ian_]
DC: More scenarios:
16:08:15 [TimBL]
ack danC
16:08:43 [ian_]
- You write in HTML "I offer to sell widgets for $10" and provide a snail mail address. I send money and you say "No, I sell for $20." You can be sued today.
16:08:44 [TimBL]
Scaenario 1 -- you advertize stg for $10 but later charge $20, you get sued
16:09:05 [ian_]
- One step away: you write the same thing in well-defined schema. You should also get sued.
16:09:07 [ian_]
NW: Right.
16:09:27 [ian_]
NW: The distinction that is made is that I initiated this by publishing a quote in some recognized format.
16:09:40 [ian_]
...if I receive a response to that quote, I have to honor the meaning of that quote.
16:10:03 [ian_]
DC: I agree - difficult to take on obligations by doing a GET. It's the publisher who takes on the obligations.
16:10:36 [ian_]
DC: I said at ftf meeting that as long as you have a context of http + email, mime type + bits is enough to get meaning.
16:11:18 [DanC]
something like that, yes.
16:11:42 [DanC]
in particular: I think TimBL had the HTTP/email context implicitly in mind when he asked about mime type+bits; I think it's worth keeping explicit
16:12:21 [DanC]
note: I've modelled a very small part of HTTP; not publishing, in particular.
16:12:23 [ian_]
q+ PC
16:12:28 [DanC]
16:12:45 [TimBray]
16:12:53 [ian_]
TBL garnering consensus: Perhaps the relationship is between the first half and second half of TOC. Perhaps my static view assumes the underlying protocols.
16:13:15 [ian_]
TBL: And I have a set of documents with authors and access. I hear NW and DC asking why I would assume that.
16:13:35 [ian_]
TBL: I would hope that in the architecture we attack both of these questions - we address the cases where the context is assumed and when it is not.[
16:13:57 [ian_]
TBL: We should define "Web meaning".
16:14:09 [ian_]
q+ NW
16:14:12 [DanC]
speaking of TimBL's TOC, I re-published it [oops; need forward link as well as backlink] in wiki space
16:15:48 [Norm]
That's a lot more context than just the servers running...
16:16:12 [ian_]
TBL: You can process a document in all kinds of ways. But I think you can't convey the intent of a document unless you respect the specifications used to compose the content.
16:16:41 [ian_]
TBL: You are authorized to say what a document is by going through the steps set forth by the specs that the author has used.
16:17:03 [ian_]
q+ IJ
16:17:09 [ian_]
q- PaulC
16:17:12 [TimBray]
16:17:14 [ian_]
q- NW
16:17:22 [Norm]
q- NW
16:18:25 [ian_]
TBL: PC, would you agree to the statement that the SOAP spec delegates meaning of message to contained stuff?
16:18:52 [TimBL]
16:19:02 [ian_]
PC: There are multiple views. Not just simple case of something of type xml and a single processing inference. If you take SOAP, as the message goes along, there are other processing instructions.
16:19:40 [ian_]
DC: At every point, you said "look at outermost context".
16:19:47 [ian_]
PC: TBL said "hooked to mime type"
16:19:59 [ian_]
TBL: At every point, a spec gives you a little bit, and tells you where to look next.
16:20:33 [ian_]
PC: Then we are in agreement. When we write this down, make sure that we don't limit model to single processing pass.
16:21:55 [ian_]
TBL: Summarizing
16:22:01 [ian_]
1) Recusion
16:22:16 [ian_]
2) Even in SOAP case, namespace is guide
16:22:26 [ian_]
3) There is also protocol stuff (constraints on sequencing).
16:22:35 [TimBL]
16:22:45 [TimBL]
ack IJ
16:24:14 [TimBray]
16:24:36 [ian_]
IJ: With TBL we looked at classifying documents for which looking inside the document can be useful.
16:24:47 [ian_]
...expressed in terms of constraints.
16:24:55 [ian_]
TBL: IJ, please put that on queue for later discussion.
16:25:18 [TimBL]
"generic processing of xml documents" - what can you do inside an xml document?
16:25:19 [ian_]
TB: XHTML Modularization says 'when you post other stuff inside xhtml', it doesn't say anything about what the namespace should be.
16:25:41 [ian_]
TB: In the case of RDDL, RDDL is supposed to (I guess) change its formal public identifier.
16:25:55 [ian_]
TB: We may have to take the position where XHTML finds a better way to do this.
16:26:37 [ian_]
PC: Isn't there mail saying that the thesis that there's a single root namespace is wrong?
16:26:51 [ian_]
TB: I think the notion of xhtml as a host language with embedded things is a good idea.
16:27:40 [ian_]
TBL: Does the concept of "Web meaning" seem useful to people?
16:27:42 [TimBray]
16:27:47 [DanC]
yes, let's please make mixing-XHTML-with-other-stuff an issue; I think the XHTML WG would like the help; maybe I can get them to ask us.
16:28:21 [ian_]
DC: What about "Web context"?
16:28:31 [TimBray]
16:28:46 [ian_]
TBL: There are a set of contexts that have something in common.
16:29:10 [ian_]
TBL: For instance, a style sheet for me doesn't have meaning on its own; it's designed to be applied to something else. There are counter-examples as well.
16:29:31 [ian_]
DC: I think this requires more than a term. Requires a page.
16:29:34 [TimBray]
16:30:07 [ian_]
TB: Job of W3C is to tell programmers what to do to not break the Web. I'd like to see the path from findings to programmers.
16:30:17 [TimBray]
from *meanings* to programmers
16:30:23 [ian_]
TBL: The "meaning" is about what you're licensed to do with a document given certain protocols.
16:30:48 [ian_]
TBL: TB, could you have a go at your point 14?
16:31:23 [ian_]
TB: Suppose I say "Examples of things that make poor namespace documents: [TB gives primarily syntactic contraint aggregations]"
16:31:41 [ian_]
DC: No. I think the bulk of use is beyond syntactic constraints.
16:31:46 [ian_]
PC, TB: We disagree.
16:33:27 [ian_]
TB: SGML says explicitly that the document type definitions include, formally, human-readable documentation. There are more semantics than you can capture in a schema. And thus my point that schemas don't make good namespace documents.
16:33:47 [ian_]
PC: Documents that indicate valid form of a document, are poor indicators of how a document should be processed.
16:34:03 [ian_]
PC: The fallacy is that there's only one way to process a document.
16:34:07 [ian_]
TBL: No one has said that.
16:34:31 [ian_]
TBL: The schema doesn't say how to process a document.
16:34:36 [Roy]
16:34:40 [ian_]
PC: It's wrong to put something in a schema to tell you how to process.
16:34:46 [TimBray]
16:34:58 [Stuart]
16:35:02 [ian_]
TBL: People may put information in our out of a schema to explain appropriate uses.
16:35:41 [ian_]
IJ: TBL, please make sure your use of "meaning" v. "processing" is shared here.
16:36:18 [ian_]
TBL: Documents that convey the syntactic contraints are useful but limited. And namespace documents should not be constrainted to include only those docs making syntactic constraints.
16:36:23 [ian_]
TB: I can agree to that.
16:36:30 [TimBL]
q+ PC
16:36:32 [TimBL]
16:36:38 [Roy]
16:36:42 [ian_]
Action TB: Rewrite point 14.
16:36:45 [TimBL]
ack TimBL
16:37:14 [TimBL]
useful but insufficient
16:37:48 [ian_]
(In short, RF said that syntactic content at end of URI namespace is useful but insufficient.)
16:37:57 [Roy]
I feel that both Tim's are saying Schemas are useful but insufficient for defining a namespace.
16:38:19 [ian_]
[Meaning v. processing]
16:38:58 [Roy]
what does that have to do with syntactic content at end of URI?
16:38:59 [Stuart]
16:39:05 [Stuart]
16:39:38 [ian_]
TBL waxing: There are a wide set of protocols that connect meaning to protocols. For example, for invoices: you can be given an invoice in many ways. There are a huge number of technical microprotocols that convey the meaning of the invoice in a message. Delivery of a message is very useful (and general). We can separate the definition of delivery with what you do with an invoice once received.
16:40:13 [ian_]
TBL: Protocols would start: "If you have received an invoice, then you can...."
16:40:49 [ian_]
TBL: "Absolute meaning" is meaning in a wide set of contexts. And meaning is shared by anyone using shared protocols.
16:41:01 [ian_]
....there is a set of contexts where interpretations are all the same.
16:41:19 [ian_]
TBL: I could define a new protocol and say "When you get these bits, it's just like you received by email."
16:41:35 [Norm]
TimBL: what you just said is not the impression that I got from what you said at the f2f. If you write down what you just said, I might agree.
16:41:35 [ian_]
TBL: We may have two concepts: delivery of a message v. publication of a document.
16:41:46 [ian_]
16:41:48 [TimBL]
16:41:49 [DanC]
16:42:06 [DanC]
to make an agenda request (re Tag Wiki
16:42:17 [ian_]
PC to TB: Does your note consider the possibility that there will be namespaces for which no schema?
16:42:30 [DanC]
"definitive material" <- that's what I've been calling 'schema'. I'm willing to stop using 'schema' for that.
16:42:42 [ian_]
TB: No. I do say that nature of material in namespace document is unpredictable. And may be found in multiple places.
16:43:22 [TimBL]
16:44:13 [ian_]
TB: We should make strong claims that namespace defining materials should exist, and other claims about the nature of that material.
16:44:38 [ian_]
PC: My working group has several namespaces for which there is a human-readable definition that points off to other documents. No schema for it.
16:44:58 [ian_]
PC: The reality is that I will be reluctant if we tell people they have been using namespaces wrong for 2.5 years.
16:45:02 [TimBray]
16:45:32 [ian_]
TBL: I think we agree that the more you make available, the better. I only hear disagreement on whether an indirection is necessary when you only have one document.
16:45:35 [Dave]
Dave has joined #tagmem
16:45:46 [TimBL]
16:45:53 [DanC]
Zakim, what's the scheduled duration of this telcon?
16:45:54 [Zakim]
I don't understand your question, DanC.
16:46:08 [Norm]
What whas it TimBray said, "aaauurggh!?" :-)
16:46:09 [TimBL]
topp of the hour
16:46:14 [ian_]
PC: I don't want us to make the assertion that the only acceptable definiting material is an xml schema.
16:46:19 [DanC]
thx, timbl
16:47:06 [ian_]
TB: I am doubtful about namespaces that only have one defining document. One anomolous exception case: sole defining material is human readable document.
16:47:26 [DanC]
the query function namespace isn't documented by just one document; it's documented by a bit of XHTML that points to the rest of the XML Query spec.
16:47:45 [ian_]
TBL: I have a question -
16:47:58 [ian_]
I have an RDF schema that describes various properties using DAML terms.
16:48:03 [TimBray]
16:48:49 [DanC]
ian_, does TimBL have an action about giving CVS access to folks? is that done?
16:48:54 [ian_]
TBL: There are descriptions in my RDF schema. Because you can put descriptions of each property in the schema, if you put some human-readable documentation that is *not* in the schema, that's not a good idea: don't store data in 2 places.
16:49:19 [ian_]
TBL: You should put human-readable comments in the schema since machines can find them, can be passed on, etc.
16:49:23 [ian_]
DanC: Yes.
16:49:36 [ian_]
s/DanC: Yes/IJ responding to DanC - yes, TimBL is done./
16:49:52 [ian_]
At ftf meeting, people agreed they have enough to get accounts and CVS access.
16:50:24 [ian_]
TB: I think there are two goals:
16:50:38 [ian_]
- In the case of the DAML application TBL cites, obviously goal is to allow machines to do work.
16:51:12 [ian_]
- But if I don't have that software, I need other mechanisms to get human-readable output without DAML software.
16:51:25 [ian_] ideal document would be that the namespace material explain what processing is expected.
16:51:29 [TimBL]
16:51:35 [TimBray]
16:51:37 [TimBray]
16:52:02 [ian_]
16:52:07 [ian_]
DC: Do we have shared writing space?
16:52:26 [ian_]
TBL: People can get accounts and write using CVS (under /2001/tag/)
16:53:03 [ian_]
DC: Do we have expectation about using CVS space?
16:53:18 [ian_]
PC: Just haven't done yet.
16:53:33 [ian_]
DC: I put up a wiki for world-writable access
16:53:38 [DanC]
I put up a wiki
16:53:43 [ian_]
TB: I have a concern that this could be time-consuming.
16:53:50 [ian_]
TBL: What's the expectation that the TAG will read and respond.
16:53:55 [ian_]
DC: I offer to summarize it weekly.
16:54:22 [ian_]
PC: I have concerns about opening a second channel.
16:54:36 [ian_]
DC: I haven't settled on www-tag as the only channel.
16:55:23 [ian_]
DC: I'm concerned that we haven't made progress on arch documents. I think outsourcing this is a good idea.
16:55:43 [ian_]
...also, design issues doesn't have consensus, it would be useful to find out where people don't agree.
16:56:00 [ian_]
PC: I'm concerned about high cost of second channel.
16:56:09 [ian_]
TBL: I suggest putting a label on the wiki as experimental.
16:56:49 [ian_]
PC: For a lot of mail on www-tag, I like to be able to forward email to people I think will be interested. We work that way.
16:57:10 [ian_]
TB: Having said that, I see Dan's point about not knowing where there is not consensus on design issues.
16:57:30 [ian_]
DC: I'm observing that there has been no progress on outline.
16:58:05 [TimBray]
This *group* is the gating body for this document
16:58:38 [ian_]
DC: What if I write in toc directly?
16:58:46 [ian_]
TBL: Don't put something in without notifying people.
16:58:56 [ian_]
DC: What about "I wrote this section; unless you say something it will say."
16:59:13 [TimBray]
I'm turning into a pumpkin at this point... bye
16:59:22 [Zakim]
17:00:23 [DanC]
a section
17:00:27 [ian_]
DanC: I'll put my writeup in CVS if that's what is desired. I'll feel very constrained if I can't write directly to the arch document.
17:02:10 [ian_]
DC: When will we have an architecture document?
17:02:12 [ian_]
TBL: Good question.
17:03:02 [ian_]
IJ Proposes - I can spend my time better on things other than writing meeting summaries.
17:03:25 [ian_]
PC: I would like an arch document for May 2002 AC meeting. I hope we can have a template for our report to the AC then.
17:03:33 [ian_]
TBL: I can see us having a TOC with a number of findings.
17:04:16 [TimBL]
17:04:31 [ian_]
DC: I think I can describe web architecture in a page.
17:04:46 [ian_]
PC: The TAG has started bottom-up (addressing people's issues).
17:04:59 [ian_]
PC: If DC is willing to supply top-down material, we should take advantage of this.
17:05:12 [DanC]
would others be interested in top-down in parallel?
17:05:27 [Roy]
I'd prefer editing XML via CVS
17:05:54 [Roy]
with metadata tags to indicate consensus (or lack)
17:06:05 [ian_]
Resolved: IJ will not write meeting summaries.
17:06:06 [ian_]
17:06:22 [ian_]
Next meeting: 25 Feb for those who will be available.
17:06:24 [ian_]
17:06:34 [DanC]
17:06:47 [ian_]
DC: This is my first draft of slides for the plenary.