- From: Norman Walsh <Norman.Walsh@Sun.COM>
- Date: Tue, 02 May 2006 14:49:31 -0400
- To: www-tag@w3.org
- Message-ID: <87k6949s90.fsf@nwalsh.com>
See http://www.w3.org/2001/tag/2006/05/02-minutes.html
W3C[1]
- DRAFT -
TAG
2 May 2006
Agenda[2]
See also: IRC log[3]
Attendees
Present
Ed, T.V., Vincent, Norm, Henry, Noah, Dan, Tim
Regrets
Dave
Chair
Vincent
Scribe
Norm
Contents
* Topics
1. Administrative
2. Issue siteData-36
3. Issue metadataInURI-31
4. Issue schemeProtocols-49
5. Issue namespaceDocuments-8
* Summary of Action Items
----------------------------------------------------------------------
Administrative
Next telcon: 9 May 2006
No regrets given
Next scribe: Henry
Approve minutes of last telcon
->http://www.w3.org/2001/tag/2006/04/25-tagmem-minutes
Approved
Approve today's agenda
->http://www.w3.org/2001/tag/2006/05/02-agenda.html
VQ takes NDW's action to announce namespaceState-48
Thank you, Vincent!
Issue siteData-36
<scribe> New message from Mark Nottingham
->http://lists.w3.org/Archives/Public/www-tag/2006Apr/0041.html
VQ: Issue is currently on the some-day pile. Should we take it up again?
<noah> BTW: Noah notes that the HTML agenda at
http://www.w3.org/2001/tag/2006/05/02-agenda.html[7] has an erroneous
<title>Agenda of 25 April 2006 TAG teleconference</title>
DanC: I had an action but no longer recall what it was
<noah> The header is correct: <h1>Agenda of 2 May 2006 TAG
teleconference</h1>
DanC: There's another well-known location thing related to access control
in Flash
... Or, at least, I hear there is one.
... How would P3P work without a well-known location?
TimBL: Here's how it should work: HTTP head should return a site-metadata
header pointing to where to get the stuff
DanC: Head and not options?
TimBL: Options is web-dav
... Then you read the RDF that you got.
<timbl_> HEAD to the /
<timbl_> Metadata: /foo.rdf
<timbl_> GET /foo.rdf
I thought we were going to give this a standard name. The last "standard
name" ever required.
DanC: That's three round trips for the first access
TimBL: Advantage is that you could put the metadata on any request.
... In foo.rdf, you'd get pointers to whatever you wanted
Noah: Is this for typical access to a site, or is it just for crawlers?
DanC: Current practice is to grab metadata (like /favicon) on every
request
Scribe observes some confusion about whether or not we're talking about
access control here
TimBL: When do people need access control?
<DanC> (it's just that access control problem is likely more complex than
the favico problem. though the favico situation is sorta tolerable, since
the Link: header is deployed, to some extent, in that case)
TimBL: A responsible JavaScript/Voice browser/etc. client can get the
access control to find out if the resource is intended to be available to
scripts from that domain
TV: This may be easiest if we begin with non-executable content like CSS
... You can link to the CSS files on w3.org from your site, for example
... In the voice browser case, there are dialogs. You need to know if you
can use the dialog from another site. So you need to know if it's ok to
use and if use puts you at any risk.
TimBL: I think there's a third one: even though you're allowed to use it,
is it in fact confidential. Will the script that's using your credentials
to get it leak it to the outside world.
TV: Perhaps we should factor out the credentials. Are they on a per-use
basis, or can the client hold onto them forever.
TimBL: Whether you've got the rights to use it are covered by access
control. The hairy thing is when a script written by one person is used by
a second person to access data from a third person.
... In original in HTTP there was a method: thing and a public: thing to
try to provide some information about what was public.
<timbl_> Public: GET
DanC: The use case that sticks in my mind is that American Airlines uses
Fedex to ship. They're happy with fedex going into their site to get data,
but they're not happy to have the public do it.
TV: Fedex needs a token.
TimBL: Tokens can be leaked so it's hard to control.
TV: Everybody today is using tokens and timing them.
Noah: The broader solutions are to use things like Kerberos. Fairly simple
things can only be expected to go so far.
Norm: So, would having site metadata help?
DanC: There is already metadata, the question is do we want to do it
better.
... I think you can no longer use some URIs because, for example, using
/flash.xml may give scripts access to things
... Maybe we should advise that well-known locations involve trademarks
<DanC> 1/2 ;-)
Vincent: Should we separate access control and siteData-36? I'm not sure
if Mark wants more progress on site metadata or simply on access control.
<timbl_> b
DanC: I'd love to review some solutions
TimBL: Do you think the header idea is too difficult to roll out?
DanC: Not hard, but round trips are the most expensive thing. Going from
two to three is not something I can advise.
Noah: Is it the number of round trips or the timing?
... I think what I'm hearing is that today the browser is going to hit
both the data and the metadata (favicon).
DanC: The P3P case is the screw case, you can't get the data until you
have the access control.
Noah: But in the non-P3P case, it sounds like I'm already doing two round
trips.
(Scribe was called away; a few minutes were lost here)
DanC: There's a link in the head that you can avoid the well-known
location
Norm: Yes, if you have the link, the request for the well-known location
is not made
Noah: Isn't the status quo two round trips anyway?
DanC: Well, the headers
<noah> From Wikipedia:
<noah> <link rel="icon" href="http://example.com/favicon.ico[8]"
type="image/x-icon" />
<noah> <link rel="shortcut icon" href="http://example.com/favicon.ico[9]"
type="image/x-icon" />
<DanC> NDW reports 1st-hand experience making /favico.ico 404s go away by
use of <link rel="icon" ... />
<noah> See: http://en.wikipedia.org/wiki/Favicon[10]
DanC: I can answer Mark and say we're noodling on it, if you have any
ideas, let us know.
TimBL: Are we noodling on it? What are we going to do?
DanC: I can see some options and I don't know which ones are better than
the others
Maybe we can get some discussion going on www-tag
<DanC> (for the record, you just continue my action.)
VQ: What to do about actions?
DanC: If there's a draft he was working on, I'd like a pointer
<DanC> ah...
http://www.tbray.org/ongoing/When/200x/2004/01/08/WebSite36[11] <-
http://www.w3.org/2001/tag/issues.html#siteData-36[12]
DanC: With that pointer, I'm happy to drop his action
VQ: I suggest we drop his action. Any objections?
<scribe> Dropped.
VQ: I'll drop it and make sure we don't lose the link to what Tim did.
The action to DanC is continued
Issue metadataInURI-31
<noah> See note I just sent at:
http://lists.w3.org/Archives/Public/www-tag/2006May/0002.html[13]
VQ: For the rest of the agenda, I tried to make an update on the draft
findings
<noah> Gives status of (non)progress on metadataInURI and schemeProtocols
VQ: When we discussed this last month, we were expecting to make progress
by the end of April
Noah: I promised I'd be done, but I haven't finished yet.
... I'll try real hard for two weeks from now, definitely three.
... A few minutes review might be useful.
... Recently, we've had a couple of emails, especially from Roy
<noah> Roy's email:
http://lists.w3.org/Archives/Public/www-tag/2006Mar/0063.html[14]
<noah> I had used as an example: http://example.org/book/chapter2[15]
<noah> Infer: http://example.org/book/chapter1[16]
Noah: I said, look, I think people who read this URI on the side of a bus
infer that this is about chapter 2 of a book and that the obvious edit
would give us chapter 1
... There's no absolute gaurantee that this works unless the provider has
made that promise.
<timbl_> identifier vs metadata
Noah: Roy said you're conflating the identifier with the metadata
<timbl_> connected question is semantics on identifier
Noah: I'm guessing that this thing lives in a structured world and has
siblings and that is metadata
TimBL: I've heard this discussed under the rubric "semantics of
identifiers"
Noah: I'm not sure it's decidable whether I did this for one reason or
another.
<DanC> (this always reminds me of 4th grade English grammar class where we
learned when to use "which" vs "that".
http://en.wikipedia.org/wiki/Relative_pronoun[17] )
Noah: People infer connections in a way that wouldn't come up with UUIDs,
whether it's named by chapter numbers or chapter titles.
TV: People are able to infer things from titles or names that they
wouldn't be able to infer from UUIDs
HT: Any story that doesn't make note of the redundancy of human-readable
URIs is missing something
Noah: Is it metadata?
<DanC> (why do we care whether it's "metadata" or not? the point is that
it's redundant and hence enhances reliability.)
TV: I don't know, but it's useful information.
<DanC> (oh.)
HT: The other property that readable URIs have that UUIDs don't is that I
am able to determine whether or not I think I got the right thing back.
Noah: It's useful to name things in ways that promote certain kinds of
inference.
... I tried that and got back "bad example, that's not what we mean by
metadata"
<DanC> (interesting point about surprise or not; I make it a habit to
quote other stuff along with a URI so that the consumer can treat the URI
as completely opaque and use the _other_ stuff in my citation to confirm
that they got to the right place.)
Noah: One case is where I structure the identifier itself to promote
certain kinds of inference.
... To me it makes sense to go there.
... I think it's commonly what we see; even the .jpg case is like that,
even though we want to warn people that you can't rely on that.
... If I've warranted something about an identifier, then you can rely on
it. But even if I don't warrant it, you can be in the realm of guessing
and find useful stuff.
... Suppose I'm a publisher. I can just makeup opaque IDs. TV said, no
you're losing something when you do that. There's no gaurantee, but it's
useful.
... So the question is, to what extent do you want to describe this to
resource owners.
<Zakim> DanC, you wanted to reiterate a point about freedom of choice and
how it's constrained by dictionaries and encyclopedias whether people like
it or not
<DanC> http://en.wikipedia.org/wiki/Relative_pronoun[18]
Discussion of chapter3 vs. "chapter title"
<DanC> no, norm, both of those are restrictive.
Scribe believed that's what was being discussed
DanC: It might be nice to say "before you pick a URI that's based on the
title, consider that you might want to change the title without breaking
everyone's links"
Noah: I'll see if I can come up with a story for the next draft
Issue schemeProtocols-49
VQ: This is for Noah again.
Noah: I don't think we ever agreed to publish anything on this topic
Issue namespaceDocuments-8
Norm: I still need to tidy up the loose ends with Jonathan
Norm will be prepared to give an updated status report next week
VQ: Henry, what about your action?
HT: The bug is still bumping along the bottom
... I'll get back to it next month.
DanC: I reported something the XQuery names
->http://www.w3.org/2005/xpath-functions/
Norm: There's a bug in the QT bugzilla to fix that, to make the "/" go
away. That will happen on the next round of publication.
<DanC> http://www.w3.org/2005/xpath-functions#compare[20]
That's the address of the compare function.
DanC: The extra slash is a bug, right?
Norm: Yes
<noah> Would you get back RDDL or regular HTML?
<DanC> GET /2005/xpath-functions
<DanC> id="compare"
You'll get HTML back, probably with RDDL in it.
<noah> Thanks.
DanC: From one set of specs you'll learn that that URI identifies an HTML
element.
... You'll also be able to determine that it identifies an XQuery
function.
... So it identifies both, or the URI is ambiguous, or...
Noah: This came up in SOAP. There was a side discussion just like this.
Does the fragment identify the documentation subsection or the artifact.
... I'm puzzled about why that ambiguity is either not there or is benign.
DanC: I think it's darned useful. That is, it's useful to have a URI for
the compare function because I want to use it. And it's nice when I can
stick it in a browser and see the right thing.
... I'm trying to figure out how to wedge this into web architecture.
Noah: The other thing is whether we do connect to get back RDF or RDDL>
TimBL: My model of this originally was that the semantics of the fragid is
determined by the content type.
... So if you do conneg then you have to be careful that the fragids all
mean the same thing.
<DanC> (indeed, my wedge involves changing the XHTML media type to say
that authors can "opt out" of the section-of-the-document meaning)
TimBL: I don't believe that the query function is an anchor, those are
distinct ideas.
... Either we say that really identifies the function and the HTML display
is some sort of fallback. I think that's weak because of the huge amount
of HTML that's out there.
... If you put an rdf:ID on the node instead of an xml:id, then it would
be reasonable to say that that identifies the concept not the element
<noah> So, this seems to sort of work if the RDF is in the documentation
page, but not if the RDF is standalone, right?
TimBL: You could build completely consistent documents this way.
<noah> Furthermore, it sort of implies that we don't have a first class
name for the function itself (or it's a different name we haven't yet
discussed.)
TimBL: There's a push to put RDF in HTML so the ability to have both in
the same document may be reasonable.
Norm: Do I put both rdf:ID and xml:id, or is rdf:ID supposed to move the
browser display?
TimBL: If you give a URI that identifies something with the rdf:ID, then
the browser should switch to a "data view"
DanC: That undercuts everything I said before
TimBL: It's very hairy to tie these things together in a good way
DanC: Only philosophically.
... We should find some way to explain what's actually going on
TimBL: If you don't fix it philosophically, then the TAG just has to clean
up all the corner cases later one.
DanC: that's really cheap compared to asking every web document to change
<Zakim> noah, you wanted to discuss resources and representations
Noah: To me, the questionable part of the architecture is secondary vs.
primary resources. I think it'd be easier to say that the resource is the
function and the page you get back is a representation of it.
... In the case of secondary resources, the story has a lot of texture,
but it smacks of when there is a primary resource, the secondary resource
is grounded in that representation.
... Now it seems like we're struggling to say how we exract the abstract
thing
Broader discussion of primary vs. secondary resources
Noah: We seem to have different web mechanisms available for what we call
primary and secondary resources
... Partly I'm not 100% happy with where we landed on the namespace
document.
... I don't tend to think of a namespace as a document, for example. I can
ask questions about the document that don't make sense about the
collection of names.
TimBL: You're not happy with the namespace URI identifying the namespace
document.
Noah: Yes.
... On a common-sense way, I'd like to say that the namespace (which may
be an information resource) and the namespace document are different
things.
... I'm not convinced that that's a better place to be
<Zakim> ht, you wanted to wonder about context of use
HT: I was opposed to this in the httpRange-14 discussion, but maybe it's
the right answer here.
... Taking as a starting point that there's something right about current
practice, let's make a story that explains current use.
... These things are ambiguous (that is, URIs with fragids in namespace
documents). It's context of use which determines which of those you're
talking about.
<timbl_> I believe "use disambiguates" works fine in natural langauge and
leads to a hopeless mess in logic.
<noah> To be clear: I'm OK with the HTML or RDDL coming back as a
representation of the namespace resource -- the tougher question is
whether the resource itself is the documentation, or the namespace itself.
I'm a bit on the fence, but still inclined (unlike Tim) to view it as the
namespace itself.
<noah> By the way, I think the namespace is an information resource, but
it's not quite the same as the info resource that is the documentation
about the resource.
HT: If it's in an HTML anchor, it's the document, if it's somewhere else,
it's the resource.
... We don't have a place to talk about that in the architecture, but
maybe we need to think about going there.
TV: Why is the fragment identifier there?
... I have a protocal, then a host, then a whole bunch of hierarchical
structure.
... In the HTML case, the fragid took you to a place in the document
... CGI did it in a completely different way. If I had a/b/c/d, then if
"b" was executable, c/d got passed to "b"
... HTML forms never leveraged that structure, but the advantage is that
you didn't have to have a different identifier on the client and the
server.
... Maybe "#" was a mistake. Maybe we should have said
"myhomepage.html/chapter1" and who cares if chapter1 is a section or a
separate file.
... the "#" is a sort of wart that was there for jumping to IDs.
... Any time you have a special case like that, there will be lots of
corner cases.
... I'm not saying that we should remove "#" but we should think about how
we might "do it right"
... For a lot of cases, there's no reason to distinguish between the
client and server side.
DanC: The client and server could work it out
TV: That would also give you an interesting way of allowing the mobile
space to different things with the same URIs.
Noah: Let's say you did that. Now, how does the client know how to act on
the hierarchical URI?
... If you knew the media type of the document returned, then you might
now. But that raises complications because it ties the resolution to the
interpretation of another representaiton.
<DanC> (wierd post-hoc answer to "maybe # was a mistake" is: well, nothing
stopped anybody from undoing the mistake ala TV's thought experiment, and
they didn't, so maybe # wasn't a mistake.)
Noah: There's the possibility, for example, that fragments of different
sizes might be in different media types
VQ: We need to stop here, but we can discuss this further next week
<DanC> (we did access control, to my satsifaction)
<noah> Um, I'm not at all sure # was a mistake, but good or bad it's
pretty well baked into HTML and browsers. I don't think we can infer a lot
from the fact that most of us are still using # to name HTML fragments,
except that it's what works.
Adjourned
Summary of Action Items
[End of minutes]
----------------------------------------------------------------------
[1] http://www.w3.org/
[2] http://www.w3.org/2001/tag/2006/05/02-agenda.html
[3] http://www.w3.org/2006/05/02-tagmem-irc
[7] http://www.w3.org/2001/tag/2006/05/02-agenda.html
[8] http://example.com/favicon.ico
[9] http://example.com/favicon.ico
[10] http://en.wikipedia.org/wiki/Favicon
[11] http://www.tbray.org/ongoing/When/200x/2004/01/08/WebSite36
[12] http://www.w3.org/2001/tag/issues.html#siteData-36
[13] http://lists.w3.org/Archives/Public/www-tag/2006May/0002.html
[14] http://lists.w3.org/Archives/Public/www-tag/2006Mar/0063.html
[15] http://example.org/book/chapter2
[16] http://example.org/book/chapter1
[17] http://en.wikipedia.org/wiki/Relative_pronoun
[18] http://en.wikipedia.org/wiki/Relative_pronoun
[20] http://www.w3.org/2005/xpath-functions#compare
[21] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[22] http://dev.w3.org/cvsweb/2002/scribe/
Minutes formatted by David Booth's scribe.perl[21] version 1.127 (CVS
log[22])
$Date: 2006/05/02 18:44:14 $
Received on Tuesday, 2 May 2006 18:50:05 UTC