See also: IRC log
<scribe> Scribe: Norm
<scribe> ScribeNick: Norm
Date: 02 May 2006
Next telcon: 9 May 2006
No regrets given
Next scribe: Henry
Approve minutes of last telcon
Approve today's agenda
VQ takes NDW's action to announce namespaceState-48
Thank you, Vincent!
<scribe> New message from Mark Nottingham
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 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)
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.
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.
ack. one sec.
Can someone scribe for me!
I'm back. Sorry
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" type="image/x-icon" />
<noah> <link rel="shortcut icon" href="http://example.com/favicon.ico" 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
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
TimBL: We should collect some use-case scenarios and then see how they play out.
DanC: Are you volunteering?
TimBL: Nope, I think we should co-opt Mark
NOTE TO SCRIBE, CLEAN THAT UP
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: With that pointer, I'm happy to drop his action
VQ: I suggest we drop his action. Any objections?
VQ: I'll drop it and make sure we don't lose the link to what Tim did.
The action to DanC is continued
<noah> See note I just sent at: http://lists.w3.org/Archives/Public/www-tag/2006May/0002.html
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
<noah> I had used as an example: http://example.org/book/chapter2
<noah> Infer: http://example.org/book/chapter1
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 )
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.
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
... 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
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
VQ: This is for Noah again.
Noah: I don't think we ever agreed to publish anything on this topic
Norm: I still need to tidy up the loose ends with Jonathan
Norm will be prepared to give an updated status report next week
HT: The bug is still bumping
along the bottom
... I'll get back to it next month.
DanC: I reported something the XQuery names
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.
That's the address of the compare function.
DanC: The extra slash is a bug, right?
<noah> Would you get back RDDL or regular HTML?
<DanC> GET /2005/xpath-functions
You'll get HTML back, probably with RDDL in it.
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
<ht> Everybody get dropped?
<ht> Weird, I can't hear anyone -- will try again
Broader discussion of primary vs. secondary resources
Noah: We seem to have different
web mechanisms available for what we call primary and secondary
... 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.
... 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
... 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
... 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
... 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
... 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.
This is scribe.perl Revision: 1.127 of Date: 2005/08/16 15:12:03 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/todays'/today's/ Succeeded: s/public/available to scripts from that domain/ Succeeded: s/reserved names/well-known locations/ Succeeded: s/From wikipedia/From Wikipedia/ Succeeded: s/usfeul/useful information/ Succeeded: s/infernece/inference/ Succeeded: s/represntation/representation/ Succeeded: s/BTW:/By the way,/ Succeeded: s/exmaple/example/ Found Scribe: Norm Inferring ScribeNick: Norm Found ScribeNick: Norm Present: Ed T.V. Vincent Norm Henry Noah Dan Tim Regrets: Dave Agenda: http://www.w3.org/2001/tag/2006/05/02-agenda.html Found Date: 2 May 2006 Guessing minutes URL: http://www.w3.org/2006/05/02-tagmem-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]