W3C 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

Not covered:

Action item review

Closed:

Open:

New:

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 $