Chris Ridpath
We resolved that the canonical form of EARL will be XML RDF, but that SBP will create an appendix of the EARL Spec with some EARL examples in n3 and provide references for n3 info. (A "rant space" for SBP who feels that n3 better represents the RDF model than XML RDF).
Jim Ley started a thread about date not being sufficient to identify a report uniquely, especially for content that is generated dynamically. We did not come to any conclusions today, but identified the following issues.
Date is clearly not sufficient for webpages, as so many pages don't provide accurate last-modified, so you can't tell just from a date of evaluation if they've changed. We would like some way to identify structural identicalness so a report can still be valid.
Suggestions:
Many pages change continously but in very minor ways, or only in content rather than structure. People put things like "todays date" on a page. Invalidating a report because of such a minor difference is annoying. Adverts are another problem with changing
Issues
waiting for nick - skip to 2nd agenda item: earl 1.0
wc: it's great!
sbp: properties list - incorporated into the spec.
wc: what needs to happen next w/1.0?
sbp: cmn made good comments. need to agree on canonical syntax. jim's client works by going through xml dom. useful to have earl in rdf syntax. could then do xslt. generally opposed to rdf, due to problems it causes. 2nd issue: how useful is it for people to implement? wanted this to be more talktative. 1/2 way between tutorial and spec. read through and get into lang, as well as define. cmn said: link to syntax examples rather than include in draft. personal preference - want feedback. template might be useful, others link.
(useful to keep in) feedback on how easy to read and know what talking about.
sbp stable for months, but constantly evolving, but slowly. but can't tell how to evolve, until people implement. rdf good for evolving. when parsing, depends on syntax. how to tell what type of earl, syntactically. important in rdf. earl on cutting edge of rdf. basic rdf langs, like annotea and dc, low level. earl is structured compared to those too complex?
wc summary of agenda items from sbp: complexity, feedback and evolution, usability of new spec, canonical form
sbp: could do: everything in this doc asserted by... in rdf, implicit defn of what's going on in doc
wc asks for clarification of last point
NK: Q: I'm using XML (+XSLT) for all new developments. ??? feasible to think about moving to XML::RDF and making it all EARL compliant? Don't know..
sbp: going through - http://lists.w3.org/Archives/Public/w3c-wai-er-ig/2001Nov/att-0006/01-1.0spec.html#syntax
sbp: loads of people reviewed one site. assertor elements. people rating the page. alternative: that info for the doc itself. implied assertor element for the doc. easier to parse and create, but less specific. only one person can assert per doc. if wants loads of people, ... earl dependent on context info
NK: Why .. only one person can assert per doc?
sbp: good to get canonical syntax. people think element tree instead of model, i think in terms of model. xmlschema good idea.
* wendy voices nick's questions to thsoe on the phone
sbp: not even sure technically possible or sound to move in that direction, but make it easier. the way things happen in rdf, you have statements - ground facts. reified facts in the doc. e.g. this page passes x x passes or fails guideline x says that y says... question is: should we have quoting or not. if don't have quoting, can only have one person saying something - the author that's what's impiled in rdf benefit, don't use reification
NK: User review requires subjective statements: "I have trouble with that ..." chaals has been against
/* wendy reads nick's question */
sbp: don't think the benefit outweighs the advantage of reificaiton
CMN: no, you can have multiple people who each say "I think something" about a single subject
NK: .. where "that" may not necessarily be very well-defined
NK: ('cos yer average surfer doean't speak our jargon)
sbp is hanging up the phone, and joining via irc [10:33]
NK: sbp on one line?
yes.
NK: metoo :-(
WC: jim and i are also hanging up phone. no use if all the action here on irc.
WC: so, when sbp joins, we'll finish discussion of how we might change how we make earl assertions.
WC: then, there are several other items on the agenda:
JL: I think we need multiple "people" saying things within one Earl document, I can't see how it would be useful otherwise
/* sbp joins irc. wc and jl hang up phone. from here on out, only method of communication is irc */
NK: Agreed
sbp - you just missed:
JL: I think we need multiple "people" saying things within one Earl document, I can't see how it would be useful otherwise
SBP: Yes, I agree with that
sbp notes draft spec. at: http://lists.w3.org/Archives/Public/w3c-wai-er-ig/2001Nov/att-0006/01-1.0spec
NK: Is that the same as the email attachment you sent couple of weeks ago?
JL: Yes.
SBP: the only thing is that in that case, you simply have to put up with reification; even if there is only one person saying something in the entire document. Of course, it's difficult to say things about the root context anyway, unless you'r using N3
SBP: yes, that is the same attachment; I have played around with it a little bit, but my local copy is basically 99% the same
JL: We'll give you reification, if you give us XML-RDF :-)
NK: Nick mused earlier:
NK: Q: I'm using XML (+XSLT) for all new developments. ??? feasible to think about moving to XML::RDF and making it all EARL compliant? Don't know..
JL: Sean, you said there were some complications in doing this - what were they?
SBP: Chaals on a similar subject:-
SBP: [[[
SBP: It would also be good for the group to formally agree that the canonical
SBP: syntax is XML RDF, or to formally agree that there are two syntaxes and a
SBP: defined conversion algorithm, or whatever.
SBP: ]]]
SBP: the problem with parsing XML RDF as XML is that you're going at it syntactically, and the important thing about EARL is the model
SBP: OTOH, it would be possible to define a canonical form, which would then be easy to parse
NK: Why is that a problem?
SBP: and indeed, write
SBP: it's a problem because it's much more difficult to write a proper parser for EARL in XML RDF. Of course, the thinking is that you go via. an RDF parser, and then use that
SBP: an RDF parser is a kind of abstract equivalent of an XML DOM interface for a normal XML document tree
JL: I like XML, because I have XML parsers available across all servers, and major clients (IE/Mozilla) I don't have RDF parsers available to use.
SBP: where a DOM would let you access parts of the XML tree, an RDF parser lets you access parts of the model. Now, the problem is that people want to access parts of the model through the tree. THE only way to get around that is to define a canonical form
NK: XML is a representation. When you don't want EARL (e.g. generating HTML from it), just ignore the fact that it's earl-ish
NK: Yes, XML offers lots of tools
SBP: "When you don't want EARL [...], just ignore the fact that it's earl-ish" pardon me?
NK: If I use XML:RDF and can make it both XML and EARL
NK: this is what may or may not be feasible
SBP: apologies, I still don't follow
CMN: I was under the impression taht there are tools to work with RDF in XML format (which is after all the normatively defined syntax for RDF)
SBP: yes: http://www.w3.org/RDF/#developers
NK: OK, leave it for now. If you don't follow, it probably doesn't make sense
CMN: which allowed access and manipulation of the model (I agree that is the important thing)
SBP: it's the important thing, but if we can get away with having a simple syntactic form too... :-)
NK: My Q: is, can't it be both at the same time?
SBP: It will be both... but in essence, any DOM implementation would be a hack subset of an RDF parser
SBP: Jim's excellent EARL client is bascially doing that; what we want to do is extend the hack that he started
SBP: all he does is sniff for a certain URI in the XML RDF EARL, pass or fail, and then use it
JL: XML parsers are much more ubiquitous though, if we say XML-RDF for interchange of earl, how you process them yourself is up to you.
NK: I thought Jim's client worked by XML-ising it
SBP: Jim: yes, that's the thing... we should give a choice; Nick: Jim's client works on XML-ized EARL, of course :-)
JL: (the original client did that Sean, the current backend is a little more bright!)
SBP: ooh, do you have a pointer?
NK: So each of us treads our own little pathway :-)
JL: Same url, it's only a little brighter, and there's no front end to it.
JL: http://www.e-media.co.uk/earl/earlClientFull.0.2.zip
NK: Jim - did you see my last nights post to the list? Bookmarklet to add user feedback facility to Valet service?
NK: Might be interesting fodder for your Client?
JL: Yep, my main problem is the crippling of the HTTPRequest object in Mozilla or we could do very nice things in at least 2 browsers.
WC: back to the canonical form...
NK: I'm licensed to do things with Hotjava .. another thought ....
WC: sbp: in http://lists.w3.org/Archives/Public/w3c-wai-er-ig/2001Nov/att-0006/01-1.0spec you say "the canonical form of EARL will be in XML RDF, and XML RDF is also the only serialization recommended by the W3C. Therefore, throughout this draft, we shall use XML RDF."
WC: therefore, sounds like XML RDF it is. however, chaals suggested creating a conversion algorithm between xml rdf and n3.
CMN: if we are defining n3 as one of two canonical formats, we need a conversion.
WC: chaals - there is an n3 to rdf conversion. aaron swartz wrote it.
CMN: right. I suspect there are several.
CMN: but we don't need to annoint one if we only have one format.
CMN: people can use whatever they like, but they are responsible for checking that it does the round-trip properly
JL: I don't believe so Chaals, I only know of Aaron Swartz's and I've yet to get it running under either PythonScript or cygwin python...
WC: which brings up the point (again) of an EARL validator.
SBP: Aaron Swartz's what?
jim - aaron has a web interface - give it the uri of the rdf or n3 and it will convert it.
NK: chaals - that's fine, but it would be nice not to have to write it myself ...
CMN: if we trust aaron's toy we can use it.
JL: His N3 - RDF conversion - yes I know he has a web interface, but that's hardly friendly or efficient if I have to throw any N3 my clients get through his interface.
NK: URL?
CMN: if we prefer someone else's we can swap to that.
SBP: http://purl.org/swag/n3tordf
JL: http://swag.webns.net/n3tordf
SBP: *please* use the purl.org address... pretty please? :-)
WC: true.
CMN: If we nominate a conversion as accurate we are bound to make sure it works. I would rather leave that in Aaron's lap
SBP: You could define something like a SOAP interface to it. DanBri is keen on it, Aaron hates it
CMN: plus he is probably smarter than me anyway at making sure it works ;-)
SBP: n3tordf just uses CWM. You can have that running locally
JL: on win? I've not yet...
SBP: http://infomesh.net/2001/cwm/
CMN: Right. So if DanBri makes his own SOAP-based toy, anyone who likes SOAP can use that, and people who want it locally can install cwm, and people who want the web thing can use aaron's
JL: (and preferably in ActivePython, not a standalone version, so I can interop with ECMAScript easier.)
SBP: Jim: do you have Python installed? it should be a simple matter of getting the files and putting them in a directory. That's it
SBP: chaals: yep
JL: Always missing libraries with both versions of Python I have installed...
SBP: ah... why not just scrape 2.1.1 off of the Web? http://www.python.org/2.1.1/
WC: it sounds to me like we might be moving towards n3 as the canonical form if people are able to get the conversion tools working? it seems that nick and jim would prefer xml rdf since they already have tools that work with it. sbp is still pushing/favoring n3 b/c it better represents the rdf model. cmn doesn't care much as long as the conversion works correctly.
NK: OK, conversion tools appear crucial
SBP: well, I'm fairly neutral on the subject, because I don't have to implement it :-)
chaals favours XML because 1) It is the formally defined W3C Recommendation syntax
CMN: 2) it also defines the model OK (unless you are intersted in hand-coding RDF, which I am not)
WC: the spec currently says, xml rdf. it doesn't sound like anyone has a problem with that.
JL: XML unless there's some chance of N3 parsers available on clients, Mozilla, IE ship with XML parsers, neither have N3 parsers.
CMN: (My preferred method of building stuff by hand is to use a graphical interface tool like RDFAuthor
NK: RDFAuthor .. wozzat?
WC: sbp - how about a section in the spec about n3 - a reference section that includes aaron's conversion tools, n3 examples, etc.?
WC: schema already in n3...
SBP: Even DanC says that N3 is not really a stable transmission format; just a poor-mans authoring tool... but what an authoring tool
WC: appendix a
CMN: It's an application for drawing node-arc diagrams and making them RDF - works on MacOS, and there is now a port for the folks who don't have Mac OS X
SBP: the schema can be translated...
SBP: I'm certainly not going to author the schema in XML RDF, though! What a mess
WC: ok then - sounds like there is consensus to use xml rdf as canonical form.
JL: Agreed.
NK: yea
sbp stays out of it...
WC: also that there is interest in n3 and tools to convert between xml rdf and n3.
chaals assumes that Sean can convert the schema to XML RDF with a tool.
WC: do people think that there should be an appendix in the spec about xml rdf vs n3?
SBP: chaals: yes, I can just drag and drop it onto the CWM icon on my desktop, and press "x"
SBP: there should be an appendix in the XML RDF spec about XML RDF vs. N3 :-)
JL: If Sean thinks it would be useful to people to think of it in N3, then of course.
chaals makes schemas in XHTML and a conversion thing DanC wrote
CMN: it is pretty basic, but so is my ability to make schemas ;-)
WC: the point of the appendix is to give sbp a place to discuss the beauty of n3 and convince people to use it rather than xml rdf. :)
SBP: the problem is that you can't actually use the XHTML at the namespace... that's a real pain in the rear end
SBP: heh, heh, my little rant space :-)
wendy searches summary of points sbp raised earlier
NK: visions of sbp in the pulpit .. and there shall be n3 :-)
WC: points sbp raised during earlier comments: complexity of earl, feedback and evolution (process of developing earl), usability of new spec
WC: plus, other issues from published agenda:
WC: - Schematron - Nick asks "is it useful to continue development on this?"
SBP: heh, it was a good way to resolve the issue: use XML RDF, but give Sean a little space to say, "don't use XML RDF - it sucks! use N3!"
WC: - Jim's EARL client, and the question that came up about combining results between EARL reports.
WC: - date not being sufficient to identify a report uniquely, especially for content that is generated dynamically.
WC: what do people want to discuss next?
JL: I quite concerned about the DATE thing, and identifying what's been evaluated.
WC: and for how long do we want to be here? we aren't limited by telecon schedule...but we usually only go for 1 hour, 1 1/2 max.
NK: Time of day issues? Later is better for me
CMN: I don't want to be on too much longer. although I can always catch up afterwards...
SBP: why not just go until I'm the only one left talking?
WC: lol
WC: let's go for at least 1/2 hour more. let's discuss date. jim - thoughts?
CMN: how will you know? It would be reasonable to assume we are avidly payng attention unless we say otherwise...
SBP: [process aside: could someone please mail the logs to ERT when we're done; I've missed a lot of stuff]
WC: yes - i'll clean them up and send (i.e. get rid of duplicates and msgs of people coming/going).
SBP: cheers
NK: Unique id: use standard techniques. Separate data from any such thing
JL: Date is clearly not sufficient for webpages, as so many pages don't provide accurate last-modified, so you can't tell just from a date of evaluation if they've changed.
SBP: use a hash
SBP: you can use any daml:UnambiguousProeprty, in fact
NK: Use a message-id type construct
SBP: s/daml:UnambiguousProeprty/daml:UnambiguousProperty/
JL: Yep, then we have another problem, many pages which you do evaluations on change continously but in very minor ways, or only in content rather than structure.
NK: Do we need a difference-metric?
SBP: well, there's a property defined called "sameContentAs" (or something like that), which lets you make processor specific assertions that this bit of content is the same as in another document
JL: People put things like "todays date" on a page, invalidating a report because of such a minor difference is annoying.
JL: Do you know of any Difference Metrics for HTML Nick (I asked about this in ciwa? a couple of weeks back.)
WC: assessing dynamic pages...eeks.
CMN: being able to make earl assertions about parts of a page is important - it means that you can do that and then add up the parts to see if it equals the whole.
NK: Visual Validator could deal with that, since it's working around the DOM
WC: it almost requires the author making an assertion about pieces where the text content changes, but changes do not invalidate report.
SBP: there is the tension between cramming as much detail into EARL as possible, and leaving it out to make it easy to implement. It's been a constant struggle
WC: we have author assertions already, e.g. "image alt-text is good, i promise." now they need to be able to say, "text content will change but not become inaccessible, i promise."
JL: Adverts are another problem with changing (http://jibbering.com/faq/ contains about 5% of urls which change just because of Ads.)
WC: true.
CMN: no they don't
WC: also, portals want to claim (and i'm not sure we should allow) - the structure i've provided is accessible, but the content is provided by someone else and i can't vouch for it. bits x, y, z are those things."
CMN: that bit is fine.
CMN: portal.com says "this conforms to requirements for structure."
CMN: frednerk.com says "I am the author of this ad, and tis ad conforms to content requirements"
CMN: squish it together.
SBP: lol @ frednerk.com
JL: I'm more thinking of telling when you need to re-evaluate a resource - evaluation is likely an expensive activity requiring a human (at least for some reports) if we can't tell if when a report is no longer valid then we need humans to go and look.
SBP: TimBL wrote a bit about this, and there are some schema terms: http://www.w3.org/DesignIssues/Generic
CMN: right. But then if we don't know whether something is good, that is what we actually need anyway.
NK: isEquivalent(1.0, "this text", "that text") - no human required when changes
NK: (things like date)
JL: So could we define a hash within EARL to at least cope with the pages that are static?
SBP: problem is that there are different types of equivalence; you can say that one bit of content is the same as another in terms of what it discusses, but that the latter is now written in clearer English
NK: ohbugger
SBP: well, you can use ?x log:content [ crypto:sha ?y ] .
SBP: or I can have earl:sha do the same thing, but it's a bit fecky
WC: i like the idea of identifying pages that are static, although concerned that if author's realize using this will cause them to be bugged less, they might use it more often.
NK: No, not entirely a problem; different evaluations ahve different equivalences
SBP: { ?x earl:sha ?y } log:implies { ?x log:content [ crypto:sha ?y ] } .
NK: wendy - Site Valet already does that in effect
SBP: If would could agree on a canonical hash format, that'd be good, because then you can merge reports
WC: nick - cool. didn't realize that. it asks the author?
NK: Use - widely supported, etc
SBP: for example, someone asserts something about the page with MD5 hash pj08wjf0e8w, and someone else asserts something with the SHA hash pjsf09wesfg89us089g... you don't know if they're the same pages or not, and if you don't have the original, you never will
SBP: no, no new schemes, just a canonical hexified hash
JL: I use MD5 hash.
SBP: er... hexlified, rather :-)
SBP: I prefer MD5 too, but SHA is more secure
JL: but I'm easy
NK: then how to generate locally unique part doesn't matter
SBP: we can set up a Web service that will get the SHA of a page
NK: Is security really a big issue?
WC: i'm not familiar w/these has algorithms, but a quick glance at http://www.enteract.com/~lspitz/md5.html makes me wonder
SBP: import sys, sha, binascii; f = open(sys.argv[1], 'r'); m = f.read(); f.close(); print binascii.hexlify(sha.new(m).digest())
NK: Ahem - we already have a hash. It's called ETag
WC: if the has value will change if just one character on the page has changed. it seems as if that is what it is saying. ETag?
NK: Why not use ETag?
NK: HTTP header
CMN: Yep, seems like a smart has to me
SBP: you'll have to use it in conjunction with the server address
SBP: and hope that the server doesn't change
WC: http://mail.anywhereyougo.com/pipermail/wap-dev/2001-January/016615.html
CMN: (It is the thing that Henrik andd Jose did to solve the Amaya lost update problem...)
SBP: and remember that not all servers use ETags
NK: lynx -dump -head http://www.webthing.com/
NK: ...
NK: chop
JL: The servers? - it's something in control of the author of the page which means they can fool the earl client.
NK: ETag: "201c8-fc9-3b9e8a41"
SBP: IIS doesn't appear to add ETags to any dynamic (ASP) pages
NK: So identify
CMN: There are things where a hash isn't appropriate.
CMN: and a URI is.
SBP: [ earl:hashTag "201c8-fc9-3b9e8a41@www.webthing.com" ] .
NK: Now when we have multiple reports on that page
JL: I also deliberately send identical ETags for pages which have changed...
CMN: For example, saying that something which is generated by an ASP meets some requirement about structure, or has an address element in it might be valid for things where the content changes wildly
JL: (as I'm happy for the old version to still be viewed.)
JL: This is my point Chaals, I'd like some way to identify structural identicalness so a report can still be valid.
NK: Structural identicalness? Make a hash of a DOM?
CMN: no.
CMN: say that whatever the has is,, the URI still meets the requirement.
CMN: s/has/hash/
JL: I'm more thinking of external evaluation where you need to tell if the author has changed the page so the assertion is no longer valid, how do we externally know it's changed?
CMN: Part of the whoole "how do we use this" thing is whether people are expected to say "that earl fragment doesn't confomr to :theTruthAsWeKnowIt"
CMN: knowing it has chagned: you do need to provide enough information to identify the important bits - a kind of partial hash.
JL: I think they should, certainly I envisage people reporting "this is wrong" if the client says something, which would schedule it for re-evaluation.
CMN: or hashing over one or several XML fragments.
NK: We can't know everything about the Now (back to date). We can reevaluate based on Etag or LastModified
CMN: wrong: right, but the question is whther you say "that report is wrong" or whethert you produce a conflicting report and have rules about how to deal with merging reports when there is a conflist.
CMN: a la CSS
JL: I think we need to be able to combine reports which say different things (with potentially different reliabilities) but how to deal with conflicts depends on the use that the EARL is put to.
NK: Jim - agreed
SBP: yeah...
SBP: but that is of course what we do already
NK: are we in danger of debating angels on a pinhead here?
CMN: rules for merging conflicts: we nned them.
SBP: there's merging the reports just as a matter-of-fact "python cwm.py x.rdf y.rdf", and there's coming to conclusions about the result "python cwm.py z.rdf --think"
CMN: It might be the easiest way to add more info - use the conlflict rules.
SBP: well, I can come up with the rules files
SBP: but it's difficult to assess conflicts
CMN: if ?x says B and then ?x says A, believe A before B
CMN: if A says ?X and B says ?Y believe A before B
SBP: well, there's conflicts between people, and there's conflicts within one person (one person saying two different things)
CMN: right. there are a few different types of situatuion.
CMN: we need to codifyu enough of them to make this workable...
chaals needs to go, - I have a call of my own on in a minute.
SBP: using RDF makes it very feasable to create standard rules that anyone can use and apply... but the disadvantage is that there's only one decent tool that I know of that can grok them
WC: it also means there are a finite number of rules.
SBP: c'ya chaals
SBP: finite: yeah
WC: if several uknown people make assertions about a resource, you then make rules after the fact.. after you know who has made assertions.
NK: unnnnh ...
NK: several unknown people is crying out for human attention
JL: I still think what you do is dependant on the use of EARL, for example if you're using it to inform a user, you can present both and leave it to the user to decide - whereas if you want to make a more automatic choice then the user needs to have set up who to trust, I can't see how in EARL we can define who we should trust to report something.
WC: agreed. ok. we've gone almost 2 hours. i know i need a break. this has been good to raise the various issues.
NK: EARL can weight "lots of peole say", or "someone says this is very important"
WC: how about i summarize those, and then we can add more (if we've missed any) and use that as basis for resolving.
CMN: presenting both: this is important - it must be possible to say "I want to see conflicts and decide for myself"
SBP: yeah, a precis of the meeting would be cool
NK: (the latter being the accessibility case - one person may be uniquely disabled)
WC: nick - true. kind of like the discussion on WCAG right now: if 80% of the group agrees that this checkpoint is met, then the checkpoint must be understandable.
CMN: I don't think we define canonical rules for everyone, just example rules for people to apply.
SBP: good point
CMN: In some cases people will swap between one set of rules and another depending on their application.
CMN: (see Jim, I am starting to understand what you have been trying to tell me for a while)
SBP: when I meant standard rules, I meant rules that can be applied fairly evenly, not that they should be applied by default
chaals isslow, but often gets there eventually ;-)
NK: metoo, chaals
SBP: Homer: Something said, not good...
WC: ok. i'm going to end the "meeting" now, but y'all want to keep talking - great! is everyone up for meeting again next week? we've got some interesting issue to discuss
NK: Time of day anyone?
SBP: nah, let's pack it in and move to QA already
WC: lol
SBP: :-)
WC: actually, we should schedule a joint call or something with QA. i'll chase that up.
JL: Hmm... I'll've been in the pub lunchtime, and won't be available evening...(it's me b'day)
NK: IRC often active around midnight GMT +-
at least get some communication going.
CMN: happy birthday Jim.
SBP: your birthday today?
JL: next monday
SBP: Happy Birthday, indeed!
JL: Next monday, not today..
SBP: for then :-)
NK: welcome to the ranks of the middle-aged :-)
JL: Oy, 28 ain't middle-aged...
chaals requests that we have a bit of debrief time for ER to explain where it is at to AU at some point.
SBP: you can do that for us, chaals :-)
WC: midnight GMT is 7 p.m. Eastern US., right?
NK: guess so
WC: (picking up on Nick's comment that irc is more active then)
JL: http://www.timezoneconverter.com/cgi-bin/tzc.tzc
JL: :-)
NK: Me, xover, sbp, aaronsw often enough on
SBP: yeah
WC: yep, that's what i'm using, but i never feel sure about it. :)
JL: I've never seen it it's just at the bottom of your emails..
WC: :)
SBP: heh, heh
chaals just guesses.
WC: monday is out for jim. tuesday is out for me. what about next wednesday? GMT midnight? irc? or are you all around this wednesday? we could pick up on this discussion?
SBP: should be
NK: wendy, yes to whatever you say
JL: Should be..
WC: nick: lol
WC: ok then - this wednesday, GMT midnight, irc. we'll continue the discussion of EARL And what-not. I'll summarize today's main points to help with that.
$Date: 2001/12/09 01:52:25 $ Wendy Chisholm