TAG -- 2 May 2006

<scribe> Scribe: Norm

<scribe> ScribeNick: Norm

Date: 02 May 2006

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 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.

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:

<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> ah... http://www.tbray.org/ongoing/When/200x/2004/01/08/WebSite36 <- http://www.w3.org/2001/tag/issues.html#siteData-36

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

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.

<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

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

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

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

<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 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

- DRAFT -

TAG
2 May 2006

Attendees

Contents

Administrative

Issue siteData-36

Issue metadataInURI-31

Issue schemeProtocols-49

Issue namespaceDocuments-8

Summary of Action Items

Scribe.perl diagnostic output

- DRAFT -

TAG 2 May 2006

Attendees

Contents

Administrative

Issue siteData-36

Issue metadataInURI-31

Issue schemeProtocols-49

Issue namespaceDocuments-8

Summary of Action Items

Scribe.perl diagnostic output

TAG
2 May 2006