W3C home > Mailing lists > Public > www-tag@w3.org > December 2007

TAG telcon Minutes for 13th Dec 2007

From: Norman Walsh <ndw@nwalsh.com>
Date: Thu, 13 Dec 2007 15:03:06 -0500
To: www-tag@w3.org
Message-ID: <m2ejdql5vp.fsf@nwalsh.com>
See http://www.w3.org/2001/tag/2007/12/13-minutes

W3C[1]

                                   - DRAFT -

                          Techical Architecture Group

13 Dec 2007

   Agenda[2]

   See also: IRC log[3]

Attendees

   Present
           Norm, Rhys, Stuart, Henry, Raman

   Regrets
           Dan, Timbl

   Chair
           Stuart

   Scribe
           Norm

Contents

     * Topics
         1. Accept minutes from last week?
         2. Next telcon: 10 Jan 2007, Dan proposed to scribe
         3. Issue httpRedirections-57 - a week in the life of ISSUE-57
         4. Rich Web Clients: Client State and Frag IDs
         5. Review of "Access Control for Cross-site Requests"
         6. Any other business?
     * Summary of Action Items

     ----------------------------------------------------------------------

   Stuart: Dave will be 30 minutes late and we may have partial regrets from
   Noah
   ... Dave requested we swap items 2 and 3.

   Norm attempts to summarize the XML 2007 conference.

  Accept minutes from last week?

   Accepted.

  Next telcon: 10 Jan 2007, Dan proposed to scribe

   No regrets given

  Issue httpRedirections-57 - a week in the life of ISSUE-57

   Stuart: There was a lot of energy at the end of last week, thought we'd
   see if we could keep it going.

   Henry: I did a small amount of experimentation. For different reasons,
   neither Apache 2.0 or 2.2 will allow you to use rewrite rules to generate
   a response code outside the published range.
   ... In the course of doing that, I discovered that Apache does already use
   207 for something already.
   ... I had to hack much harder, using CGI, to produce other response codes.
   None of the browers I tried it on (IE/firefox) complained.
   ... Unfortunately, that means that until and unless we get the IETF to add
   a response code, I don't know of any way to easily play with a new
   response code (because you can't get Apache to do it)
   ... I think Noah tried on a few other browers and didn't have any trouble.

   Timbl: Changing the IETF is one thing, changing Apache is another.
   ... Changing the source in Apache is also difficult.

   Henry: It's actually not hard to make the changes in the source

   Timbl: I think if the TAG resolved this was important and we had a patch,
   I think we'd have a strong argument for getting it into the trunk of
   Apache 2.x
   ... But maybe some of the early adopters would be happy to patch. And the
   IETF would be impressed if we already had it in Apache.

   Stuart: There are other ideas going around, description-id,
   description-header, etc. One of my colleagues suggested a header
   containing an RDF statement.

   Timbl: Looking at the 207 problem, a very pragmatic way to go forward
   would be to add a new header.
   ... This also lets the SemWeb build on the Web which uses 200 for pretty
   much all successes.
   ... The description-id tells you were to go to get the ontology in the
   future. This would let 200 documents point to RDF.

   Henry: My starting position, same as last time, is, "gee, I hate to break
   200 that way"

   Norm: On the other hand, for folks who don't get heartburn about 200
   responses for non-information resources, it will seem just fine.

   Stuart: The distinction between information resources and things that
   weren't worked fine, pragmatically, because it let us finish the webArch
   document. But the question has come up again, what is the utility of the
   distinction?
   ... I know we don't want the ambiguity, but why does that force an
   ontological distinction?

   Timbl: Focusing on the class is putting the cart before the horse. Maybe
   it's much more helpful to think about what the 200 means.
   ... It means "this is the content of the document you asked for".
   ... It's difficult to say without document, but we could say "the bits
   that came along give you the meaning of the thing you asked for"
   ... That means information resources are things that have meaning.
   ... If you say it's the document content, then those are the things that
   have information content.
   ... Now you get folks coming to this new and they have to answer the
   question "is a protein an information resource?"
   ... In fact, no, you just ask them if it's the meaning of the protein or a
   description of it.

   "Meaning of the protein?" they'll say, that doesn't make any sense.

   scribe: So that's not an information resource.

   Scribe missed some thread about the word representation from REST

   Timbl: Now when we talk about the meaning of the document in RDF, you get
   a bunch of triples. So now we have a cleaner model.
   ... There are questions about conneg too. You shouldn't conneg between
   things that have different meaning. It's a fundamental misunderstanding to
   conneg RDF with something else.

   Henry: I'd add, if you don't distinguish between the RDF document that
   contains an XML representation of the RDF triples about the eiffel tower
   and the eiffel tower, then you can't make assertions about one without
   making assertions without the other.
   ... It looks like the answer for things like the Eiffel Tower is you
   should just use the hash convention.
   ... The problem that leaves us with is for things on the old fashionned
   web where it makes sense to distinguish between things in the old
   fashioned and their descriptions.
   ... I guess that's a legacy problem, but I don't think most of us are
   prepared to walk away from that problem.

   Timbl: Legacy problem?

   Henry: I want to be able to distinguish between the XML namespace and the
   XML namespace document.

   Timbl: Namespaces are hard, another example?

   Henry: There are the legacy semweb URIs that don't have hashes

   Timbl: But we have 303 for those

   Henry: Looking around, you do find a fair number of assertions about URIs
   without hashes.

   Timbl: Some people just don't like the hash.

   Some discussion of the practical consequences of hashes

   Stuart: Let's move on to item 2 in the hope that Dave will arrive soon

   Timbl: pushback on description-id?

   Stuart: I think it slightly perverts what 200 means. So I feel about like
   Henry.
   ... I used to think that you could serve a representation of a depiction
   as a proxy.
   ... We'll use separate URIs for a dog and the dog, but actually it's ok to
   serve the picture as a representation of the dog.
   ... There is a question of what really distinguishes a representation and
   a description.

   Timbl: To me, it's really clear. The library card about Moby Dick and Moby
   Dick, there's a level of indirection.

   Stuart: But I could describe a document in excrutiating detail, where
   every letter on every page is. That would be a description.

   Timbl: There are lots of descriptions that might include enough
   information to get the document.

   Stuart: I don't think it's impossible to provide a web representation of
   Mars.
   ... If you are going to use a plain HTTP URI for Mars, then don't deploy
   representations there, but use redirections.

   Timbl: That's httpRange-14!

   Norm: I think the description-id thing sounds good.

  Rich Web Clients: Client State and Frag IDs

   Stuart: I put this on the agenda this way because I think Rhys has an
   action along these lines that he's completed. Raman also has an email and
   blog post about URIs.

   Rhys: I took an action to look at a couple of AJAX libraries to see if
   they provide support for creating URIs for application state.

   <Stuart> trackbot-ng, ACTION-50?

   Rhys: I picked Dojo and Scriptaculous (which actually uses Prototype)
   ... As it turns out Dojo does have some support and Scriptaculous doesn't.
   ... The interesting thing was that actually Dojo seems to provide this
   help in order to allow end users to use the back button in a sensible way.
   ... So they seem to have concentrated on doing things in a way that will
   allow the browser's history stack to work in a reasonable way.
   ... Consequently, they use fragids. There are API calls, like
   add-to-history(), that allow a particular fragid to be associated with
   that state.
   ... So as long as the application is prepared to restart at the right
   place given the URI, it could be used.
   ... But it doesn't really give you support in recreating the state, only
   in labeling it.
   ... As for Prototype and Scriptaculous, I couldn't find anything at all
   that helped.
   ... But Raman has posted a pointer to how Google lets you do this.

   Raman: There are two threads there. What Google Maps does predates the
   Google Web Toolkit.
   ... The Google Web Toolkit lets you build web applications. It has a
   history token that allows the javascript application to build its own
   stack for browser history.
   ... Effectively, what they really do on complex user interfaces, is make
   the back/forward buttons work as undo/redo.
   ... As long as the application programmer does the right thing, the
   compiled javascript manages the stack.

   Stuart: And the blog?

   Raman: Even before the blog, I started with an example from the CNN
   website which uses a fragid in a very special way
   ... They basically have a chunk of videos that they want you to be able to
   view. Just as an ID attribute was used in HTML, they're using the fragid,
   munged through javascript, to get you to the right part of the video
   stream.
   ... If you view today's CNN site as an application, then the fragid is a
   pointer into the state.
   ... Mark Birbeck pointed me to something he's doing in the Sidewinder
   product (it serves web applications on the desktop)
   ... Sidewinder uses the fragid to pass parameters to the Sidewinder client
   ... So I invoke the application as a URL and I customize how it behaves on
   the client by using the fragid with XPointer.
   ... This goes back to the question I raised even before the CNN example.
   Over time, we've come up with an inequality.
   ... At the beginning of time, there was htbin and cgibin so server-side
   parameters got a "?"
   ... On the client side, you had the "#" and everything that comes after
   the hash was dependent on the client and the media type.
   ... On the server-side, 15 years later, things have become much more
   sophisticated.
   ... But the client-side has been pretty stagnant.
   ... So for the TAG, the question is, is there something we can do to help
   with the client side evolution.

   <Zakim> Rhys, you wanted to say that the way the CNN videos works is the
   same kind of thing as would happen with dojo

   Rhys: The way the CNN video site works, is effectively exactly what you'd
   get if you used the Dojo mechanism to create the state.

   Norm: I pushed back a little bit about the Sidewinder use of fragids. Mark
   replied that there's no specification of what XPointer means, so why can't
   he use it?
   ... I walked away wondering if he was right.

   Raman: I think it's great, I'd say the same thing, it's time to start
   telling people what they can do, not what they can't.

   <Stuart> http://www.w3.org/2001/tag/doc/state.html[4]

   Timbl: If we don't have an issue, I'd like to open one as a container for
   this.

   <Rhys> Actually, I noted that I couldn't find anything that said that
   using fragid for state, even in HTML, was a violation.

   Timbl: It'd be great to have these nuggets written down somewhere.

   Raman: I think of this as a dual to stateless URIs.
   ... There are cases where you want to do a bunch of things with a web
   application and when you pass a pointer along, it recreates that state
   ... This is just as reasonable a use of URLs as deep linking.
   ... These stateful URLs are deep linking for web applications.
   ... On the mobile web, you often find that the links totally lose the
   traversal semantics.

   Stuart: Dave, is the work you did on state relevant here?

   Dave: Potentially. It explores the use of identifiers in URIs, cookies,
   and EPRs, and talks a little bit about the tradeoffs between them.
   ... But it doesn't deal with fragids nor does it deal with generated IDs
   on the client.
   ... It assumes that the IDs are sent in the message, not generated on the
   client.
   ... If we picked up the state finding again, I think we'd want to
   incorporate this in there.
   ... Some folks wanted the state finding to be more prescriptive, but
   others wanted it to cover more cases.
   ... So there's still more work to be done in those areas.

   Raman: Instead of agonizing over what issue this goes with, I think we
   should just do the work.

   Stuart: Do you have the bones of a finding?

   Raman: I'd be happy to take on the very specific case of how its being
   done in the browser today.

   Norm: Sounds good to me.

   Stuart: Propose we open webApplicationState-58

   Accepted.

   <scribe> ACTION: Raman to write a finding about the current state of
   application state management on the web. [recorded in
   http://www.w3.org/2007/12/13-tagmem-minutes.html#action01[5]]

   <trackbot-ng> Created ACTION-91 - Write a finding about the current state
   of application state management on the web. [on T.V. Raman - due
   2007-12-20].

  Review of "Access Control for Cross-site Requests"

   -> http://www.w3.org/TR/2007/WD-access-control-20071126/

   Stuart: I did my bit of the action and posted a review.

   Dave: I've been trying to keep up with Stuart's interaction with the WG,
   but I haven't made any progress on my action yet.

   Stuart: I think it's probably worth back tracking a little bit. We
   commented earlier that they should try to align with POWDER syntax.
   ... I think that might be quite hard.
   ... Putting RDF assertions in headers might be asking too much.

   Timbl: The access thing tries to be a one-liner?

   Stuart: Or a small number of allow/deny rules.

   Timbl: If there are nested exclusions and inclusions then maybe they also
   map onto unions and intersections of owl classes
   ... But that's a separate question from whether or not there should be a
   defined mapping.

   <Stuart> rules are of the form "allow | deny pattern+ [exclusion
   pattern+]"

   Raman: The other thing I noticed is that the problem they're trying to
   solve is remarkably similar to web server apply/accept rules.
   ... I'd be much happier if they were building on something like that.

   Timbl: My experience with that is that when you have nested things, you
   really want a tree or a graph.
   ... the apache rules operate on a very tight constraint that they're
   unordered.
   ... It's a kludge because you have a separate order: deny/allow or
   allow/deny header.
   ... I wouldn't take the Apache thing as a model for a new language.

   Raman: I agree that the order by stuff is a hack, but at each level of
   nesting, you can keep the model simple by having a set of sequenced
   accept/deny rules.
   ... You can always build a more complex graph from those rules.
   ... Getting people to write the graph at the top level is going to be very
   hard to get right.

   Stuart: The current access draft doesn't have any recursion, they don't
   nest.

   Raman: There missing two things: they don't have recursion at all, and
   they don't actually refer to something that has actually been tried and
   worked.

   Stuart: Do you want to make that comment?

   Raman: Yes.

   Dave: If I understood correctly, Raman brought up that there are separate
   access/deny lists that are very similar and I think Tim said the problem
   is that the headers are unordered, and you need a tree and not a flat
   list.

   <Stuart> FYI my comments and thread:
   http://lists.w3.org/Archives/Public/public-appformats/2007Dec/0020[7]

   Timbl: Apache can't, not this draft.

   Some more discussion of how the deny/allow order rules in Apache work

   Stuart: Each rule stands on its own. Each one establishes part of an allow
   or deny rule.
   ... And deny takes precedence.

   Scribe distracted.

   Stuart: It appears to me that access control and POWDER are going in
   different directions. Asking the web access folks to take on board a
   description cast in OWL would be quite an up hill struggle.

   Timbl: Why? They don't have to write OWL, just describe things in terms
   that can be described in OWL.
   ... Could you, for example, turn what they spec into nested if's, and's
   and else's.

   <noah> Sorry to be joining so late. I hope Dan had conveyed my partial
   regrets. I thought I was beating the snow home here, but it turns out
   everyone in Boston got let out early, and all traffic was going 5mph.

   Timbl: If you can do that mapping then we can just call it a shorthand.

   Stuart: Putting that in this draft seems like it's asking a lot, do we
   want to do that?

   Timbl: I think they should describe more mathematicaly what it is that
   they're doing.

   Stuart: I tried to suggest a more declarative approach to the narrative,
   but still a narrative approach.
   ... Henry, didn't you feel fairly strongly about this?

   Raman: Getting some alignment here would be useful, but it might be hard
   get.

   Henry: It's a shame the gap is so large, but it does seem to be.

   Stuart: Tim, would you like to post a comment to the comments list on this
   point?

   <scribe> ACTION: Tim to consider whether or not he wants to post an issue
   re: POWDER/rules [recorded in
   http://www.w3.org/2007/12/13-tagmem-minutes.html#action02[8]]

   <trackbot-ng> Created ACTION-92 - Consider whether or not he wants to post
   an issue re: POWDER/rules [on Tim Berners-Lee - due 2007-12-20].

   Stuart: I put 'ping' attribute on the agenda, that's something we want to
   return to, yes?

   Dave: Absolutely

  Any other business?

   Stuart: Happy Christmas and New Year to you all.

   General acclamations of happy holidays and Happy New Year!

   Adjourned.

Summary of Action Items

   [NEW] ACTION: Raman to write a finding about the current state of
   application state management on the web. [recorded in
   http://www.w3.org/2007/12/13-tagmem-minutes.html#action01[9]]
   [NEW] ACTION: Tim to consider whether or not he wants to post an issue re:
   POWDER/rules [recorded in
   http://www.w3.org/2007/12/13-tagmem-minutes.html#action02[10]]
    
   [End of minutes]

     ----------------------------------------------------------------------

   [1] http://www.w3.org/
   [2] http://www.w3.org/2001/tag/2007/12/13-agenda
   [3] http://www.w3.org/2007/12/13-tagmem-irc
   [4] http://www.w3.org/2001/tag/doc/state.html
   [5] http://www.w3.org/2007/12/13-tagmem-minutes.html#action01
   [7] http://lists.w3.org/Archives/Public/public-appformats/2007Dec/0020
   [8] http://www.w3.org/2007/12/13-tagmem-minutes.html#action02
   [9] http://www.w3.org/2007/12/13-tagmem-minutes.html#action01
   [10] http://www.w3.org/2007/12/13-tagmem-minutes.html#action02
   [11] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
   [12] http://dev.w3.org/cvsweb/2002/scribe/

    Minutes formatted by David Booth's scribe.perl[11] version 1.128 (CVS
    log[12])
    $Date: 2007/12/13 19:59:21 $

Received on Thursday, 13 December 2007 20:03:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:51 GMT