Summary of 2002-03-25 TAG meeting
Note: This is an edited version of the 25 March TAG IRC log.
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 meeting
- Publication timeline and goal for AC meeting/WWW 2002
- Consensus on namespaces documents draft?
Not covered:
Action item review
Closed:
- 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
Open:
- 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
New:
- 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 discussion.
Decisions
Minutes
- [Ian]
- TBL: Comments on previous minutes?
- [DanC]
- 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
- [DanC]
- also put "no decisions".
- [Ian]
TBL: Are we happy with that format?
- DC: Yes.
Action item review
- [Ian]
- 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.
- [Chris]
- Yes, thats fine
- [Ian]
- IJ: What about input on section one? Not worry for this round?
- [tim]
- Agenda+ scope
- [Ian]
- 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 proposals.
- 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.
- [Chris]
- Table needs a 'due date' for actions
- [Ian]
- Action IJ: Add due date column to action item table.
- Due date for IJ action - 3 April.
Accept issue http-range-nn
- [Ian]
- Resolved: Accept http-range-nn
- http://lists.w3.org/Archives/Public/www-tag/2002Mar/0092.html
- Action IJ: Add to issues list.
Three topics for TAG presentation at May 2002 AC meeting
- [Ian]
- See proposal from PC:
- http://lists.w3.org/Archives/Member/tag/2002Mar/0072.html
- 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).
- [Chris]
- Feedback was from Tech Plenary, not clear it translates across to
AC
- [Ian]
- 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 AC.
- TBL: It's friendly to tell the AC what we'll be discussing.
- 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.
- [Chris]
- Rather,they want to see a technical summary - evidence that we are
getting to an architecture rather than disconnected spot findings
- [Ian]
- 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 stake.
- [DanC]
- hmm... I wonder if "Developing Web Architecture" http://www.w3.org/Talks/2002/02/27-wa/
, updated, would be worth the AC's time
- [Ian]
- TBL: I suggest that, as well as having 3 (process-oriented
questions), we point out top three architectural findings.
- E.g.,:
- - 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.
- [Chris]
- I wonders what the server logs would reveal about hits on ns uris vs
hits on the TR specs that define those ns URIs....
- [Ian]
- 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.
- [DanC]
- 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?
- [Ian]
- TB: I disagree. I don't think that we should track everything we ever
sent to others.
- [Tim-miT]
- one meeting please
- [Chris]
- xml-dev? ;-)
- [Ian]
- 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 dereferenceable.
- TB: Not that easy. The issues are all tied together.
- ...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 there....
- (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 stage.
- 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
- [Ian]
- 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 board.
- ...I don't want to give the AC a dart board.
- ...I'd rather have a dry "We've had four meetings...."
- 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 harmonization)
- =======================
- * W3C TAG Findings on uriMediaType-9
- http://www.w3.org/2001/tag/2002/01-uriMediaType-9
- $Date: 2002/03/25 18:02:34 $
- TB: Is this low-hanging fruit?
- [Chris]
- Low-ish
- [Ian]
- 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 changed.
- 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 them.
- ...Just making the point that once we've forwarded the issue, we
don't need to track actively.
- CL: ...DC is asking for a persistence guarantee that the IETF doesn't
like.
- [Chris]
- IANA does not like canonical URLs
- [Ian]
- TBL: I think we can use stronger language in the finding.
- [Chris]
- We are assigning an action to iANA, basically
- issue closed unless they disagree
- [Chris]
- agree we can make it a more explicit request
- should say "*existing* media types map into...."
- [Ian]
- 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 one....
- 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.
- [DanC]
- 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)
- [Ian]
- CL: Last para of findings not clear.
- ...all mime types or existing mime types?
- [Chris]
- one true base uri, or just to grandfather them?
- [DanC]
- 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?
- [Ian]
- 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 requests.
- ...the point of this is: if you want to own something, you
demonstrate your ownership of a particular http space by responding to
http requests.
- [Chris]
- again, that hits on their 'no canonical uri' culture
- [Ian]
- ...the findings doesn't say this.
- DC: I don't understand the argument that we *must have* this mapping.
I understand that it's useful.
- [Chris]
- ietf sees documents as distinct from uri, 'available at many
locations including....'
- [Ian]
- TBL: You can't dereference text/plain.
- DC: That's worth elaborating.
- [Chris]
- But (to answer Paul's point) you could have a URI urn:text/plain or
somesuch
- [Ian]
- 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 - universality)
- CL: We need to have a word for things that are URIs but not
dereferenceable.
- (CL: Should this be about URLs or all URIs?)
- [Chris]
- We clearly need a term for the class of URI that are
dereferencable
- [TimBray]
- I think there's a TAG issue in Chris' point
- [Chris]
- if we can't bring ourselves to use 'URL' which would be my
preference
- [Ian]
- 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)..........so 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?
- [Ian]
- 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.
- [DanC]
- 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.
- [Ian]
- ....that's not was envisioned when namespaces published. If that's
the direction, then TBL's argument holds water.
- [Chris]
- I once again wonder about actual hits on ns URIs, and user agent
logs
- [Ian]
- (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 document.
- CL: The thing that I noticed about TBL's argument, is that it didn't
distinguish namespace document from generic document.
- [DanC]
- to say: (1) different view of history of namespace (2) yes, justlike
a doc
- [Ian]
- CL: We can't write about the entire class of URIs. We should focus on
namespace URIs to xml documents.
- DC: I disagree with TB that no one was thinking about inferences when
namespaces was published.
- ...in my experience inference engines motivated namesapces.
- 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 resource.
- 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.
- [DanC]
- yes, namespaces is very much like xml base, except that xml base has
only the one (unnamed) prefix.
- [Chris]
- Seems TimBL is using ns URI like an entity reference
- [Tim-miT]
- (to say plan for future; plan for range of use, be minimalistic)
- [Ian]
- TBL: I agree with DC - the requirement for namespaces came from RDF.
It was decided to do this at the namespace level.
- [DanC]
- .. at the XML level
- [Ian]
- TBL: I think that there are two uses: human readable/machine
readable.
- CL: Then create optimized solutions for both cases.
- 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?
- [DanC]
- to say: self-describing web, no? i.e. "bootstrap from view source" --
T. Bray, 1st tag telcon
- [Ian]
- 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 examples.
- 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.
- [TimBray]
- any chance of hitting the speaker queue?
- [Ian]
- 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.
- [Chris]
- otherwise the issue is 'what is at the end of a URI' and the answer
is ;'how long is a peice of string'
- [Ian]
- 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
characteristic?
- 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
all.
- ...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.
- [Chris]
- yes
- [Ian]
- TBL: I'd like to get agreement among TAG participants on www-tag.
- DC: Which section of arch toc does this belong to?
- [TimBray]
- http://lists.w3.org/Archives/Public/www-tag/2002Mar/0016.html
- [Ian]
- 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.
- [TimBray]
- The above is TimBL's posting tht highlights the area of
disagreement
- [Ian]
- TBL: We could give examples that illustrate different cases: why
human-readable thing at end of ns uri is useful, ....
- [Ian]
- Adjourned
- Ian Jacobs. Last modified: $Date: 2002/03/25 18:02:34 $