Summary of 25 March 2002 TAG teleconference


The meeting summary [1] is available on the
Web and included as text below.

  - Ian


Ian Jacobs (
Tel:                     +1 718 260-9447

              Summary of 2002-03-25 TAG meeting

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

    Previous meeting: 18 March | Next meeting: 1 April 2002
    | TAG home

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

Agenda items

      * Accept issue "http-range-NN"
      * Three topics for TAG presentation at May 2002 AC
      * Publication timeline and goal for AC meeting/WWW
      * Consensus on namespaces documents draft?

    Not covered:
      * URI Equivalence (see email from DO).

Action item review

      * IJ: Integrate issues & findings into TAG arch doc
        table of contents.
      * DC: Check with workshop chair, make the XML PM ws
        minutes available to the public, per CFP

      * TB (not TBL:) Work on bullet three of introduction
        to architecture
      * NW: Send revision of "What does a document mean?"
        to www-tag. Deadline: end of business 26 March.
      * IJ: Integrate issues & findings into TAG arch doc
        toc. Deadline: 3 April

      * IJ: Add a "due date" column to action item table.
      * IJ: Accept issue http-range-14 and refer to email
        from TBL
      * TBL: Draft three points for TAG presentation to AC
        in May 2002 (e.g., 2 process issues and 1 technical
        issue, or 3 technical stakes in the ground so far).
      * DC: Work with SW to revise findings on
        uriMediaType-9 incorporating points from 25 Mar TAG


      * Accept issue http-range-14 and refer to email from


           TBL: Comments on previous minutes?

           pls put a $Date: 2002/03/25 18:02:34 $ or $Id:
           25-tag-summary.html,v 1.1 2002/03/25 18:02:34
           ijacobs Exp $ in 18-tag-summary so I can approve
           a bag-o-bits

           also put "no decisions".

           TBL: Are we happy with that format?

           DC: Yes.

   Action item review

           Open for *TB*: Work on bullet three of
           introduction to architecture
           (Not TBL)
           NW: Send revision of "What does a document
           mean?" to www-tag
           NW: Will do that today.
           DO: Write text about "Web as information space",
           to be integrated by IJ
           (Status Unknown)
           NW: Regrets for next two meetings.
           IJ: Integrate/combine one-page summaries
           IJ: I've been reading them, haven't written
           anything yet.
           DC: When should we expect harmonization?
           ...whole pile of comments on section 1.
           DC: Since we didn't get changes in last week,
           what should I expect?
           TBL: I propose that we slipped a week and get to
           Ian by Weds.
           NW: I will commit to getting two docs to Ian by
           close of business on Tuesday.

           Yes, thats fine

           IJ: What about input on section one? Not worry
           for this round?

           Agenda+ scope

           TB: Obviously some deep issues there. We should
           either publish what we've got and start that
           discussion next week.
           DC: There are a number of textual suggestions in
           the thread.
           ...I feel I owe them a yes or no on those
           TB: I think the TAG owes those people feedback
           (not you individually).
           DC: Feedback could be of the form "yes we will
           talk about that one"
           TBL: Tell people either to (1) raise issues or
           (2) indicate editorial changes.
           TB: I suggest that we assign TAG issues to
           comments people have made (e.g., does the web
           architecture encompass telnet?).
           ...I think the issues can be formulated in a way
           that supports constructive discussion.
           TBL: E.g., question of whether "web services"
           part of the web architecture. Scope issues.....I
           agree that we should assign an issue number to
           this question...scope is appropriate term?
           TBL: Suggest
           - Incorporate editorial comments into intro.
           - Log issues.
           TB: I read the thread; I will take an action to
           raise a couple of issues.

           Table needs a 'due date' for actions

           Action IJ: Add due date column to action item
           Due date for IJ action - 3 April.

   Accept issue http-range-nn

           Resolved: Accept http-range-nn
           Action IJ: Add to issues list.

   Three topics for TAG presentation at May 2002 AC meeting

           See proposal from PC:
           TBL: At least one person has requested some
           technical content in top 3 to AC.
           PC: I don't think DO suggested a particular
           technical issue.
           DC: I agree that I'd like to see one technical
           topic. Torn between "what do URIs name?" on one
           end, and "how does web services fit in?" The
           ends are: how do old things fit in and how do
           new things fit in?
           ...we could ask the AC if they agree with, e.g.,
           how URIs work. "Does this help you?"
           ...what end of the spectrum should we attack?
           TBL: I've of two minds about whether AC should
           be discussing tech issues.
           TBL: It's good to keep AC on the ground (not
           just talking about process).

           Feedback was from Tech Plenary, not clear it
           translates across to AC

           IJ: AC has said they want more technical
           material; mix it up.
           PC: I don't think we need to decide today. Pick
           who will give presentation, when will slides be
           available. Recall we are meeting ftf before the
           TBL: It's friendly to tell the AC what we'll be
           IJ: What about asking them to comment on
           integrated summaries?
           PC: We could put TAG top three in March or April
           monthly summary.
           CL: I don't think AC wants to talk about a
           particular technical issue for 30 minutes.

           Rather,they want to see a technical summary -
           evidence that we are getting to an architecture
           rather than disconnected spot findings

           TBL: I propose that we find three places where
           we put a stake in the ground.
           ...e.g., where we've said "namespaces should be
           dereferenceable and useful info at the end."
           From xml-dev point of view, this is an important

           hmm... I wonder if "Developing Web Architecture"
           updated, would be worth the AC's time

           TBL: I suggest that, as well as having 3
           (process-oriented questions), we point out top
           three architectural findings.
           - namespaces should be dereferenceable and
           useful info at the end
           - No new arbitrary URI schemes (since costly)
           IJ: I'd like to hear something on "what a
           document means"
           PC: I want to point out that it would be good if
           we had a namespace document (issue 8) resolved.
           TBL: Next meeting agenda item - try to get
           resolution on issue 8?
           PC: Another suggestion on the admin side for our
           report to the AC: The Feb report pointed out
           that some issues were forwarded to other groups.

           I wonders what the server logs would reveal
           about hits on ns uris vs hits on the TR specs
           that define those ns URIs....

           PC: ...several of these issues we assigned to
           other groups in W3C. Before we go to AC, we
           should know what has happened with these issues.

           I don't expect to resolve issues (esp. 8) in a
           meeting; I intend to read something between
           meetings. What should I read in order to prepare
           for a decision on namespaceDocument-8?

           TB: I disagree. I don't think that we should
           track everything we ever sent to others.

           one meeting please

           xml-dev? ;-)

           PC: TB answered my question. I have no problems
           with that answer to the AC.
           TBL: We could discuss at next meeting whether
           we've come to consensus in this group. We have
           more consensus on some points than others. We
           should identify where we have consensus already,
           and work on getting it on the rest.
           PC: I think we have to agree to what we can
           agree on.
           ...we have to decide whether, if you have a
           namespace URI, must/should/may be
           TB: Not that easy. The issues are all tied
           ...until we have consensus on the nature of the
           thing that's dereferenced, for example, I don't
           know that I could agree on what should be
           (Previous comment from TB "..until we have...")
           IJ: On what date will we decide top three?
           TBL: Next meeting (1 April, in time for printing
           AC materials).
           DC: Who will be on stage?
           TBL: I think it's reasonable to have all TAG on
           DC: I second the idea of TBL presenting.
           Action TBL: Draft points for AC (e.g., 2
           process/1 tech or 3 process/3 stakes)
           Due date: close of business 28 March

   Publication timeline and goal for AC meeting/WWW 2002

           TBL: Early on I thought that we would have
           outline doc and findings. I'm not sure about
           findings by then. We should be prepared to
           submit outline document.
           DC: I'd like to talk about this next week. I
           think that distributing the TOC would be
           counter-productive. The TOC is like a dart
           ...I don't want to give the AC a dart board.
           ...I'd rather have a dry "We've had four
           NW: I'm inclined to agree - giving them that toc
           in it's current state is somewhat risky.
           ...I don't think it will change dramatically in
           the next few weeks.
           DC: The TOC is all over the map about how the
           TAG agrees to any bit of it.
           TBL: We haven't done consistency of terms, etc.
           TBL: Ok, let's drop that idea.
           TBL: I'm not going to promise anything to anyone
           for now (but may change after seeing results of
           * W3C TAG Findings on uriMediaType-9
           $Date: 2002/03/25 18:02:34 $
           TB: Is this low-hanging fruit?


           DC: "Draft findings of 12 Feb" makes it sound
           like everythings ok. Everything would be ok if
           registry people answered queries.
           ...and there's no action assigned to have that
           TB: Hear, hear.
           CL: Aren't we saying here that we'd like MIME
           types to work in a certain way. If those people
           come back and say "no, we couldn't do that",
           then we have an issue. But for the moment, don't
           we close and say "this is how it should be"?
           DC: But how to the registry people know?
           CL: I'm not arguing against an action to contact
           ...Just making the point that once we've
           forwarded the issue, we don't need to track
           CL: ...DC is asking for a persistence guarantee
           that the IETF doesn't like.

           IANA does not like canonical URLs

           TBL: I think we can use stronger language in the

           We are assigning an action to iANA, basically
           issue closed unless they disagree

           agree we can make it a more explicit request
           should say "*existing* media types map into...."

           TBL: "We need such a thing (URIs for media
           types). We like the idea, but we don't like the
           new URI scheme that the proposal introduces."
           TBL: I think we need to say:
           * We're happy with this aspect but not that
           I'd like to see three theses (or however many):
           * One normative mapping
           * No new URI scheme
           * Persistence policy
           TBL: Maybe we need to have a different state for
           our issues - we have resolved them but there's
           pending action elsewhere in the community.
           TBL: Like a "CR" period almost - we are done
           with this finding, but haven't gotten acceptance
           in the community,.
           DC: "Pending"
           TB: I support TBL - strengthen the finding. I
           also think "pending" status is appropriate for
           some issues, where we've taken up a position and
           then handed off a suggestion we expect to follow
           up on.

           what I intend to say: the content-type: URI
           scheme is no good cuz the whole point is that
           the organization services the relevant network
           requests (ftp/http). (2) I don't understand the
           argument that we need this mapping (when
           considering taking the ball on this)

           CL: Last para of findings not clear.
           ...all mime types or existing mime types?

           one true base uri, or just to grandfather them?

           to say: (3) any request to the IETF/IANA should
           have (a) our requirements (b) some detailed
           suggestion of how to meet them.
           what did TimBL just confirm that we're saying?

           CL: Political issue of whether to obviate
           existing registry by promoting extensibility
           through URIs.
           DC: The org that owns this registry should
           demonstrate their ownerships by answering http
           ...the point of this is: if you want to own
           something, you demonstrate your ownership of a
           particular http space by responding to http

           again, that hits on their 'no canonical uri'

           ...the findings doesn't say this.
           DC: I don't understand the argument that we
           *must have* this mapping. I understand that it's

           ietf sees documents as distinct from uri,
           'available at many locations including....'

           TBL: You can't dereference text/plain.
           DC: That's worth elaborating.

           But (to answer Paul's point) you could have a
           URI urn:text/plain or somesuch

           TBL: Good reason to use URI as identifier - if
           you come across it out of context, you can
           dereference it and get some useful context.
           (Part of architectural principles -
           CL: We need to have a word for things that are
           URIs but not dereferenceable.
           (CL: Should this be about URLs or all URIs?)

           We clearly need a term for the class of URI that
           are dereferencable

           I think there's a TAG issue in Chris' point

           if we can't bring ourselves to use 'URL' which
           would be my preference

           DC: If you own something, you have to give a
           surface mail address so you can be sued.
           TBL: I hear consensus that:
           TBL: - There should be a std way to take this
           thing and turn it into a URI that can be
           dereferenced and is supported
           TBL: - But if someone else wants to use another
           URI, should there be a mapping (e.g., within an
           enterprise) people can put a URI
           value in the content type field....
           ...I suggest we add that.
           DC: Yes, I like the idea.
           DC: Hard to explain this outside of the arch
           document. This is an example of the test of
           independent invention at work.
           Action DC: Work with Stuart to write this up:
           [Agreement that we won't summarize points here;
           read the log]

   Consensus on namespaces documents draft?

           Reviewing: "Architectural Theses on Namespaces
           and Namespace Documents"
           TBL: Let's see which ones we have consensus on.
           TB: Is it worthwhile to go throught them here?
           ...we have disagreement on theses 9 and12.
           ...deep enough to stand in the way of consensus.
           See note from TBL to www-tag about why shouldn't
           be an indirection.

           er... as somebody who was there when namespace
           were invented, I'll say it's not different from
           what was in mind when namespaces were invented.

           ....that's not was envisioned when namespaces
           published. If that's the direction, then TBL's
           argument holds water.

           I once again wonder about actual hits on ns
           URIs, and user agent logs

           (previous comment TB)
           TB: Two radically different things people want
           namespaces for: (1) simple labels, in which case
           I would argue for my thesis, and
           TB: (2) semantic web inference engine context,
           in which case requirements are quite different.
           TB: It will not be easy to come up with a best
           practice that will serve both scenarios well. If
           we can't agree, then I'm not sure I can agree
           that it's a good idea to have a namespace
           CL: The thing that I noticed about TBL's
           argument, is that it didn't distinguish
           namespace document from generic document.

           to say: (1) different view of history of
           namespace (2) yes, justlike a doc

           CL: We can't write about the entire class of
           URIs. We should focus on namespace URIs to xml
           DC: I disagree with TB that no one was thinking
           about inferences when namespaces was published.
  my experience inference engines motivated
           DC: Secondly, yes namespace documents are just
           like any other documents. Best when can be
           viewed in your browser.
           CL: Namespace documents aren't "special",
           there's just a subclass of documents.
           DC: Namespace resource is not different from
           CL: I don't agree with DC's assertion. It has a
           particular type of usage.
           CL: Like images. If I were to start talking
           about using images and then generalized to cars,
           my thesis would get muddy quickly.
           CL: Taking TBL's example apart, you've either
           just invented entities or xml base.
           TBL: In RDF, you can use more qnames.

           yes, namespaces is very much like xml base,
           except that xml base has only the one (unnamed)

           Seems TimBL is using ns URI like an entity

           (to say plan for future; plan for range of use,
           be minimalistic)

           TBL: I agree with DC - the requirement for
           namespaces came from RDF. It was decided to do
           this at the namespace level.

           .. at the XML level

           TBL: I think that there are two uses: human
           readable/machine readable.
           CL: Then create optimized solutions for both
           TBL: But you will get everything in-between. I
           don't want to draw a line here; I think we will
           see a continuum.
           CL: I'm hearing that on the one hand, RDF people
           wanted a mechanism for typing shorter URIs. We
           have produced a solution that meets needs of two
           communities, but neither very well.
           CL: ...why not instead create solutions that
           meet needs of two communities?

           to say: self-describing web, no? i.e. "bootstrap
           from view source" -- T. Bray, 1st tag telcon

           TBL: I disagree. The Web works because the
           generalization works better than the specific
           cases. I'm working towards saying "There should
           be a document; the application designer can put
           useful information there" We should give
           TBL: We should recognize that we have found 2
           applications now, but haven't thought about
           applications people will come up in 3 years.
           (Just as ":" used in URIs since there was a need
           to distinguish http and ftp initially).
           TBL: We should not constrain how the namespace
           documents are used to maintain flexibility.

           any chance of hitting the speaker queue?

           CL: How many hits do we have on the SVG
           namespace URI v the tech report?
           TB: Two things:
           (1) the notion that there is no special
           distinguished status is vacuous. Otherwise, this
           issue wouldn't exist.
           ...I think it's a useful and easily
           distinguishable subclass.

           otherwise the issue is 'what is at the end of a
           URI' and the answer is ;'how long is a peice of

           TB: (2) If you buy TBL's notion that we have two
           known applications, is this not a powerful
           argument for making indirection a desirable
           DC: I agree with TB that the issue is vacuous -
           I was surprised that this was considered an
           issue. This is all about the self-describing
           Web. Someone sends you something and you want to
           understand it for whatever reason (e.g., money).
           You view source since your desktop doesn't help
           you. In source, you find "tax:/charity...", you
           post the URI in your browser, and you view
           source recursively until you either understand
           something or you don't. The
           key is that each symbol has a home in the Web
           and you can look them up.
           DC: The idea that somehow these namespace
           documents are somehow special surprised me. Yes,
           indirection is useful in some cases, but not
           ...just like HTML documents. Namespaces need
           indirections just like everything else does.
           TBL: Time out.
           TBL: Let's take this to www-tag.
           TB: I agree.


           TBL: I'd like to get agreement among TAG
           participants on www-tag.
           DC: Which section of arch toc does this belong


           DC: Unless we say "this is part of web arch and
           it's useful to be able to look up all your
           symbols", then I don't think we'll get far.

           The above is TimBL's posting tht highlights the
           area of disagreement

           TBL: We could give examples that illustrate
           different cases: why human-readable thing at end
           of ns uri is useful, ....


    Ian Jacobs. Last modified: $Date: 2002/03/25 18:02:34 $

Received on Monday, 25 March 2002 15:23:56 UTC