W3C home > Mailing lists > Public > www-tag@w3.org > May 2006

Minutes of 2 May 2006 TAG teleconference

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


                                   - DRAFT -


2 May 2006


   See also: IRC log[3]


           Ed, T.V., Vincent, Norm, Henry, Noah, Dan, Tim





     * Topics
         1. Administrative
         2. Issue siteData-36
         3. Issue metadataInURI-31
         4. Issue schemeProtocols-49
         5. Issue namespaceDocuments-8
     * Summary of Action Items



   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!

  Issue siteData-36

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

   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

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

   (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

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

   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:

   VQ: For the rest of the agenda, I tried to make an update on the draft

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

   <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

   Noah: I'm not sure it's decidable whether I did this for one reason or

   <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
   ... I tried that and got back "bad example, that's not what we mean by

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


   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
   ... You'll also be able to determine that it identifies an XQuery
   ... 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

   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

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

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


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
    $Date: 2006/05/02 18:44:14 $

Received on Tuesday, 2 May 2006 18:50:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:12 UTC