Techical Architecture Group -- 13 Dec 2007

Date: 13 December 2007

<scribe> Scribe: Norm

<scribe> ScribeNick: Norm

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

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]

<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

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]

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

Go home says the Governor of MA, we're closed :-)

- DRAFT -

Techical Architecture Group

13 Dec 2007

Attendees

Contents