W3C home > Mailing lists > Public > www-tag@w3.org > March 2002

Summary of 18 March TAG teleconference

From: Ian B. Jacobs <ij@w3.org>
Date: Mon, 18 Mar 2002 15:52:44 -0500
Message-ID: <3C96539C.8070901@w3.org>
To: www-tag@w3.org

A summary of today's TAG teleconference is available [1].
Per requests on this list, the IRC log (also available [2])
has been edited to make it more readable. The summary is
quoted below as text.

Here's how the summary processing should work:

  * Inspired by an XSLT style sheet contributed by Chris
    Ferris [3], I asked Max Froumentin to write me another
    one that leaves the good bits from Zakim, but eliminates
    time stamps, joins and leaves, questions to zakim about
    queue, ack's of people on the queue, and combines multiple
    statements by the same person.

    If people are interested in the unadulterated log,
    it will remain available.

    The xslt style sheets we used to do this are attached.
    Prune-zakim.xsl is applied, then prune-zakim2.xsl. Thanks
    to Max for being so helpful.

  * I will then chop off manually the boring bits at
    the front and back of the result, add a summary of
    participants, agenda items discussed, and action items.

    We should be able to automate a lot of this second part
    with some standard notations, but we're not there yet.

It will probably require about 30 minutes to take an
IRC log and publish the final summary.

  - Ian

[1] http://www.w3.org/2002/03/18-tag-summary
[2] http://www.w3.org/2002/03/18-tagmem-irc
[3] http://lists.w3.org/Archives/Public/www-tag/2002Mar/0042

Ian Jacobs (ij@w3.org)   http://www.w3.org/People/Jacobs
Tel:                     +1 718 260-9447

           Summary of 18 March 2002 TAG teleconference

    Note: This is an edited version of the 18 March TAG IRC

    Previous meeting: 11 March | Next meeting: 25 March

    Participants: Tim Berners-Lee (TBL), Tim Bray (TB), Dan
    Connolly (DC), Paul Cotton (PC), Chris Lilley (CL),
    David Orchard (DO), Norm Walsh (NW), Stuart Williams
    (SW), Ian Jacobs (IJ)

    Absent: Roy Fielding

    Agenda items:
      * TAG presentation at May 2002 AC meeting
      * Review of one-page summaries of sections of
        architecture categorization

   Action item review:

      * Actions regarding one-page summaries all closed
      * DC: check with workshop chair, make the XML PM ws
        minutes available to the public, per CFP

      * IJ: Integrate issues & findings into TAG arch doc

      * TB: Work on bullet three of arch intro summary
      * NW: Send revision of summary of "What does a
        document mean?" this week to www-tag
      * DO: Write text about "Web as information space", to
        be integrated by IJ.
      * IJ: Once summaries are done, integrate them.


           Ian has changed the topic to: TAG teleconference

           Zakim, who is here?

           I see TimBL, Norm, Stuart?, Paulc, Ian, DanC,

           Missing Roy, DOrchard
           Meeting starts

           TBL: Problems with previous minutes? Additions?
           TBL: DanC suggested that we do action items by
           email in advance, or that I summarize.
           Actions for one page summaries: Closed.
           Action DC: check with workshop chair, make the
           XML PM ws minutes available to the public, per
           DC: To my satisfaction, it's public.
           ...I tested from external machine.
           Please test:
           PC: I'll publicize once it's public.

           That url is public

           TB: I strongly feel that it's public.

           I checked it

           Action IJ: Integrate issues & findings into TAG
           arch doc toc
           IJ: I will try to do that this week.

   TAG presentation at AC meeting in Hawaii.

           TimBL: Top three questions we'd ilke to ask AC?
           TimBL: What should we put out before the AC
           IJ: I suggest that I try to integrate one-piece
           documents and that that be available before AC

           Color me ignorant as well. It's a pale shade of
           chartreuse, I think.

           TimBL summarizes AC meeting
           - Twice a year, summary of w3c activities to

           Given the time period for this, we can't really
           'ask the AC' something like our three hardest
           issues and expect to get anything done in 45
           minutes or whatever

           Chris, I don't expect us to ask the AC technical
           questions. More about, say, direction of TAG.


           TimBL: AC likes to be asked, not told.
           TiMBL: The TAG should basically listen to the

           So brandishing the collection of one page
           summaries and saying 'what do you think so far'
           is the sort of question

           PC: We have a mandate to report.
           CL, yes, I think so.

           Ian describes AC agenda

           IJ: Currently, TAG allotted 30 minutes for
           presentation, 30 for discussion.
           IJ: Director usually gives a report. Is this

           TAG report is clearly separate from Director

           PC: There's also a free-for-all slot at the end
           of the day.
           TimBL: The question for us to think about:

           Recently, a move from 'presentation' to 'top
           questions/issues' to involve AC more, not give
           them bland reports

           - We are going to ask the AC for help in solving
           TAG problems. How can we use the AC to help us?
           Homework: Think about this this week. For
           discussion next week.
           If you won't be there, please indicate on IRC.
           TimBL: We can create a panel, give an overview
           of where we fit in, what we've done.
           ...and then ask 3 questions.


           PC: Here's a provocative one: TAG session wasn't
           technical enough at tech plenary. Does that
           feedback influence us about having a more
           technical discussion in front of AC? Or what
           that feedback specific to the tech plenary?
           DC: I don't mind little blood on the floor in
           DC: If we present a technical issue, I'd like to
           present by way of analogies. Allow us to
           illustrate the issue for a large audience.

           We are going for useful feedback and clarity on
           how to contribute, not 'blood on floor'
           AC is a little different to the chairs/WG
           menmber audience

           TimBL to PC: I think the AC does not expect
           technical discussion. More likely things like
           "what happens if a WG flagrantly violates the
           architecture. What can the TAG really do?" How
           do we deal with overload, etc.
           DC: Please don't get into penalty phase (until
           problems actually arise).
           IJ: Note that AB will talk about penalties for
           process violations at AC meeting.

           i.e. please let's trust unless/until we have
           reason to do otherwise.

           PC: note that we are delegating questions to WGs
           when they are appropriate. Important to tell AC
           when we do that.

           More important that AC know how to raise an
           issue to TAG, how we resolve them, etc

           TimBL: Please think about this during the next

   On one-page summaries

           TimBL: IJ has offered to put these togethers
           into a harmonious whole.
           TimBL: Also, IJ should start to create a
           glossary that will allow us to coordinate our

           yes, a glossary; e.g. web vs. Web

           I was thinking of glossary as semantic rather
           than manual of style.
           [There is consensus about doing a glossary.]

           and object/thing has come up in intro feedback.

           TimBL: If a term is already defined, point out
           where it's defined (and quote it).

           And in particular, note when there are multiple
           definitions for the same term in different

           TimBL: We are likely to rewrite terms in terms
           of each other until the whole thing is
           TimBL: There are likely traps like "entity" and
           "resource" since defined differently in
           different contexts.
           CL: I objected strongly to earlier draft, but we
           cleared up the misunderstanding.
           ...but I wanted to ensure that, e.g., DOM,
           TB: There wasn't much disagreement on the list.
           ..just a question of how we write stuff down. We
           agree that bullet 3 needs more kicking around.
           TimBL: Do you think there's still a big gap?

           for the record, the current version is
           http://www.w3.org/2001/tag/doc/intro $Revision:
           1.2 $ of $Date: 2002/03/18 20:48:04 $

           CL: Yes, it's still mostly about network
           ..less obvious; not as widely understood.
           DC: Maybe better on what a doc means?
           TB: Am I only one uncomfortable about
           distinction between documents and messages.

           message = body plus header

           TBL: DC and I share model where message is a
           "point" event. A document is something that can
           change over time.

           document is instance-of body

           TBL: You can't build a protocol out of
           documents, but you can out of messages.
           ...there's a relationship between the two (docs
           and messages).
           ..see DC's model in Larch

           Ian, an analogy to explain documents/messages:
           the way T.V. Raman (who is blind) can "see"
           what's on the whiteboard just by listening to
           the conversation (messages) about it.

           CL: TimBL on messages is fine, but seems to
           imply that a resource only changes based on
           DC: Not exactly: only time when parties learn of
           changes is when messages are exchanged.
           TimB: So sounds like agreement that item 3 needs
           more work.
           Action TB: Have a go at #3
           DC: I'm prepared to hand off now.


           IJ: I will take it as soon as TB says "Take it."
           * What does a URI identify?: NW and SW


           NW: I think we should do one more pass.
           TBL: I've never used the word "Uniform" in this
           way. I think it's a good rule.

           Stuart, are you in the critical path too? or is
           it enough if Ian hears from Norm?

           Uniform: Any URI can be used in any place where
           a URI is used.
           Stuart: In RFC 2396, there's an explanation of
           what "Uniform" is supposed to mean.
           DC: I remember this, sort of.
           DC: The spec went to the IETF as "Universal" and
           folks in the IETF found another word less
           encompassing than Universal.
           TBL: Both are important.
           TBL: I felt that "Uniform" was a kind of
           TBL: IETF resisted this apparent totalitarian
           TB: I like section 4 in second document.
           (Semantics of URIs)

           [[They [URIs] reduce the tedium of "log in to
           this server, then issue this magic command ..."
           down to a single click.]] --


           Bray: "an addressable unit of information or

           TB: I like definition of Resource: " An
           addressable unit of information or service"
           DO: Isn't that circular?
           TB: I don't care that it's circular. It works.
           TOPIC: Define "resource"

           google says that's from XML-Link, TimBray.

           TBL: In URIs and RDF used differently.

           Iput it there... but I stole it from somewhere

           From WCA terms
           The URI specification describes a resource as
           the common term for "...anything that has
           identity. Familiar examples include an
           electronic document, an image, a service (e.g.,
           "today's weather report for Los Angeles"), as
           well as a collection of other resources. Not all
           resources are network "retrievable"; e.g., human
           beings, corporations, and bound books in a
           library can also be considered resources..."
           (see also the term Web Resource).
           TimBL: You can't make a representation of a
           telnet session. Or a mailbox. I think it's
           useful to distinguish documents from other
           TimBL: HTTP has architecture of representations.
           DC: Representations are documents. But what they
           represent is not constrained, is it?
           TimBL: If something were to give me a
           representation of a telnet resource, it would
           miss the nature of the telnet resource.
           TB: My definition with service covers that.
           DC: Resource is like "point" in geometry. You
           don't define. They just are.
           CL: Yes, it's defined.
           DO: If we agree that we want a circular
           definition, then we should acknowledge that
           they're circular (and rationale why).


           TimBL: Valid questions:
           - Can a car be a resource?
           DC: Yes, n'est-ce pas?
           TimBL: By RDF definition, yes. By URI
           definition, no.
           CL: You can provide a URI to a photo of a car,
           but not a car.

           Don't especially like it, but there are examples
           of such self-booting definitions that work

           TB: I agree with CL.

           http://dm93.org/2002/03/dans-car-23423423 <-
           that identifies my car.

           TimBL: In RDF, you can write a thing that
           describes a car.

           Only because you asseret that it does
           I could assert that I have a URI which defines
           your car

           SW: The definitions I have come across are
           "Anything that can be identified can be a
           SW: Anything that can be identified is not
           necessarily everything that is net accessible.

           TimBray, if you meant to query the queue, please
           say 'q?'; if you meant to replace the queue,
           please say 'queue= ...'

           DC: Addresses take on meaning by communication.
           DC: We're not talking about unique addresses,
           just unambiguous addresses.

           TimBL said the latter

           (s/DC/TBL last comment)
           thanks DC

           The World is the Universe of Resources. The Web
           is the Universe of Network Acessible Resources

           Ian, you missed my point

           \me just dereferenced Dan's car :-)

           Sorry, the requested resource does not exist <-
           dan's car

           DO: perhaps there are computational and physical
           resources, and there is a separation between
           them in terms of addressability

           TB: In real terms, architecture is something
           developers care about. I think that a resource
           in the meaningful operational sense is one that
           can be network addressable. I don't think that
           operationally, it's useful to consider a car a


           no! please let's all lear to stop saying that
           resources can be retrieved. *Representations* of
           resources can be retrieved

           NW: I am surprised that we are having this
           discussion. I'm not sure what to think about us
           contesting the point about URIs pointing to
           real-world objects.
           NW: In response to URIs being network
           addressable, namespace URIs are specifically
           required to not be necessarily net addressable.
           SW: None of the definitions I've seen are
           "As in: This thing cannot be a resource."

           (The RDF URI#frag being different comes from the
           web architecture .. function of mime type)

           SW: I would prefer to not make the distinction
           between an HTTP-type resource and an RDF-type


           SW: ...maybe definition of resources is
           DC: Everyone please don't say "Resources can be
           retrieved." No. representations can be

           Norm, we don't need any new schemes to identify
           my car

           TimBL: It's valuable to regard HTTP as a
           protocol that talks about the class of things
           called documents. They have representations you
           can transfer as bits. So, a representation of an
           image is a set of bits that encode visual

           OK except for use of the word document

           TimBL: Around that, I feel that HTTP is
           consistent. It tells you whether it can give you
           the resource or not.
           TimBL: HTTP is built to allow you to give a URI
           to a car.

           Norm, it doesn't lead to contradiction, tim.


           From RFC2396 defn of Resource: "Not all
           resources are network
           "retrievable"; e.g., human beings, corporations,
           and bound
           books in a library can also be considered

           yes, my friggin IRC client does unauthorized

           TimBL: In RDF, fragment identifier is used to
           identify abstract concepts.
           TimBL: The way I saw getting over this dichotomy
           between two definitions is to say:
           - Without the "#", an HTTP URI is restricted to
           talk about documents.
           - You bootstrap yourself into the real world by
           defining the connection in the format.
           TimBL: I have a home page that has a URI. It was
           born in 1991. I was born in 19XX.


           TimBL: I want to be able to distinguish the car
           from the document about the car.
           TimBL: HTTP doesn't give us the ability to
           separately ask about the car and the document
           about the car.

           \me process question... do we want to make it
           through the other pieces too?

           TB: One could probably built a consistent set of
           mathematics about what a resource is. What turns
           out to be more interesting? I could see a world
           where a car has a URI. But not clear to me what
           you would build there.
           TB: Seems like a deep distinction between a
           resource that exists as an electronic object and
           something that doesn't exist.
           DO: This is the bits v. atoms discussion.

           (IMO, A car could have a URI, but not a http URI
           given HTTP 1.1)

           TB: Perhaps a resource is something you get
           representation of. The representation is always
           electronic. Perhaps that's a useful place to
           start building the superstructure: a resource is
           something that has at least one electronic
           DC: I dispute TBL's assertion that there was a
           contradiction. I agree that it's unwise to use
           the same identifier for two things (since you
           can't tell them apart).
           TBL: My interpretation is that HTTP 300, 200,
           and 404 responses all talk about documents.
           ...anytime you dereference the URI, you get
           documents. And documents and cars are distinct.
           DC: You haven't shown the contradiction in my
           assertion that "This URI identifies my car."
           CL: Why is fragment identifier in RDF not "part
           of a resource" as in other formats?
           TimBL: "Fragment" is unfortunate term since not
           always identifying a subpart. Meaning of what is
           identified is language-dependent.

           one way to say it: doc#name refers to whatever
           doc means by name.

           Dan's definition is the same as a fragment
           Tims definition is very different, it seesm

           CL: The definition here is the current
           definition of the mime identifier.


           but earlier in the meeting, we established (or
           at least: TimBL suggested) that a telnet:
           resource has no electronic representation.

           IJ: Author can choose preferred representation.
           I can therefore say "this photo is what I want
           as the representation of DC's car." It follows
           that DC's definition follows.

           TBray: A telente: resource is more lik an html
           page than a car

           SW: This discussion started as "What's a URI?".
           We moved to HTTP URIs specifically. Do we want
           to restrict ourselves to HTP URIs only?
           SW: How do we move forward/
           DC: Authors suggested they would give another


           IJ: I suggest documenting the topic inline (can
           your car be said to be a resource?)
           What does a document mean?
           NW: I propose to come back to this in one week?
           NW: No technical differences between 7 and 14
           march drafts.
           Action NW: Send revision this week to www-tag.
           Rest summary


           DC: We used "object" in intro, rather than
           "resource". Got a public comment to use "thing"

           object is problematic, what are its methods?
           thing is suitably vague

           DC: The point of the web arch is that it builds
           the illusion of a shared information space.

           we should bloody well agree what we mean and say


           DC: Please connect to other sections. E.g., Web
           servers and clients talk to each other, and the
           net effect is that everyone agrees "to what's on
           the whiteboard"
           TimBL: We need REST to create the illusion of a
           shared space. What we've been battling over is
           that most people mean "shared information space"
           but that some things are not part of REST (e.g.,
           automotive industry, telnet).
           TBL: W3C has in the past focused on the shared
           information space. But we are extending the
           boundaries (e.g., web services).
           TBL: Perhaps we should say that the information
           space model doesn't work for all things we are
           interested in. Are they in fact distinct?

           I wonder if Telnet is not 'in the web' because
           it is a stream of text?

           DC: Doesn't appeal to me on the surface.
           IJ: Dan's scanner is on the Web already.

           if so, is a streaming audio or video 'not on the

           is telnet really on the web? Hmmmmmmmmmmmmmm
           if telnet is, email is

           email very definitly is.

           DO: I support the idea that we say what parts of
           the Web conform to the notion of the shared
           information space. We should say what isn't in
           that space (if it's not).

           Any individual email message can be

           TimBL alluded earlier to mailto being in the Web
           but the email message itself not being (until
           archived, presumablky) but its clearly a
           message. And that messages are nopt on the web,
           they produce the illusion of the Web

           TB: You can give the address of a Web service
           port. You can *integrate* web services (and
           interconnections are important). But
           conceptually, the information space metaphor
           works in some areas but not others.

           DC [also said]: a lot of the work I've done for
           the last year or so is integrating my office
           phone into the web... and the IRC channels I
           cf "Real-Time Resources in the Web: IRC,
           Telephone, Instant Messaging"

           DO: I'm on Web Services Architecture WG and have
           been pounding the table to get REST components
           in the Web services architectuer.

           when I get POPmail via Eudora, it doesn't feel
           like the web is involved

           DO: Interesting to see how close various
           definitions get to qualifying.

           POP could easily be done over HTTP.

           HTTP could be (and has been) done over POP

           TB Summarizing IRC thread: Does the Web
           architecture have to comprise {email | telnet}
           as a first class citizen?

           TB: Is emaila first class citizen

           TB: How far do you have to strain your
           definition of URI to include telnet
           TBL: Split into two groups of URIs - information
           space and not.
           DC: I don't agree with that on the face of it.
           SW: What about URIs being opaque (if we are
           distinguishing them)?
           DO: What can RF and I do to change our document
           on REST?
           TimBL: Rather than just documenting REST,
           explain how it supports the information space.
           TBL: This chapter explains "if you've got
           packets, here's how you get information space"
           DO: Perhaps elsewhere in the document series, we
           should talk about shared info space.
           DO: Should this document be expanded to talk
           about the shared information space (and then
           describe how REST is used to implement that0.
           TimBL: Move the info space to the front of the
           Action DO: Write text about information space,
           to be integrated by IJ.
           What does a message mean?


           CL: I'm in the middle of writing these notes up.
           TB: RF jumped on this one because of RFC822
           TB: I would line up with RF on this.
           ...seems like the notion of 1-2 headers + bag of
           bits is pretty useful.

           line up "sorta".

           TBL: Reason why people feel headers are harmful
           is that the way they combined is not
           ....at least XML has well-defined structure. RDF
           defines combination.
           ...in 822, you don't have the structure; algos
           built on top are hard to rely on.
           TB: Having said that, it works pretty well.
           DC: About 5 work well. Very hard to extend.
           TB: But we've hit the 80/20 point.

           So, don't add new headers but use a core set
           that works already

           CL: What happened with HTTP extensions?
           DC: Didn't take off.


           TBL: Required everyone to implement mandatory
           Next meeting: Next week same time, same place.

Received on Monday, 18 March 2002 15:52:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:55:50 UTC