- From: Ian B. Jacobs <ij@w3.org>
- Date: Mon, 25 Mar 2002 15:23:52 -0500
- To: www-tag@w3.org
Hello,
The meeting summary [1] is available on the
Web and included as text below.
- Ian
[1] http://www.w3.org/2002/03/25-tag-summary
--
Ian Jacobs (ij@w3.org) http://www.w3.org/People/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
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:
* URI Equivalence (see email from DO).
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
* Accept issue http-range-14 and refer to email from
TBL
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/2002
Mar/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/2002
Mar/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 $
Received on Monday, 25 March 2002 15:23:56 UTC