See also: IRC log
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.
Accepted.
No regrets given
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.
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].
-> 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
Stuart: Happy Christmas and New Year to you all.
General acclamations of happy holidays and Happy New Year!
Adjourned.