See also: IRC log
<ht> ScribeNick: ht
SW: Agenda accepted as
... Minutes http://www.w3.org/2001/tag/2008/05/01-minutes approved
... Next meeting 15 May
NW: Regrets for 15 May
SW: jar to scribe 15 May
JR: I've prepared a document
JR: Containing use cases, at DC's
... Question is how do you get information _about_ a document given a URI for the document itself
... The driver for this is POWDER
... They're asking the TAG for input on their particular use case
<timbl> The POWDER use case is new to me .. I thought of POWDER being used it client-side use of the metdata
JR: I have found other use cases,
including GRDDL, Atom (not interested in Link header any more,
but are using their own http header?), mobile web transform use
... and the SemWeb case which got me started on this
<Ashok> Jonathan, thanks the usecases are very helpful
TVR: For the mobile web, there's
also the multiple representation case
... alternative representations from the same URL -- generic resources
TBL: In the POWDER use case the server is making all the decisions, not the client
DC: There are _two_ servers, a proxy and an origin server
TBL: The proxy (server) adapts the content
<DanC> (aha; I hadn't noticed the <blockquote> )
JR: Meta question is -- talk
about this now/next week, or wait until the f2f?
... There are a _large_ number of mechanisms proposed for this
... Link header reinstatement is in an RFC draft, but it's no longer clear who will be pushing this forward, if anyone, given that Atom has changed tack
... Some people like using a task-specific header instead of using Link with a role
WebDav's ??? is a possiblity , with an extra round-trip
scribe: ARK uses client-side URI
... Another possibility is retrieving a resource which contains pointers [scribe not sure]
<DanC> (another down-side of PROPFIND: the results aren't addressable. cf http://www.w3.org/2001/tag/doc/whenToUseGet.html )
scribe: See the document http://sw.neurocommons.org/2008/uniform-access.html for details
SW: You would like input on this doc, right?
SW: And, at best, a TAG recommendation on which way to go
JR: Right -- Phil Archer of POWDER would like guidance by June
TimBL: Between now and the f2f, accumulate comments, then talk there
<Zakim> ht, you wanted to query the categories of use case
HST: The non-SemWeb use cases
seemed to me all instrumental, rather than generic
... Which I found surprising
<Zakim> noah, you wanted to ask how busy F2F agenda is.
TBL: Well, people tend towards the specific when asked for examples
NM: Happy to discuss at the f2f,
modulo the fullness of the agenda
... It's the kind of thing we could probably make progress on via 'phone and email
... but if there's time for it, sure
<Norm> scribenick: Norm
ht: The document I circulated has
now progressed to the point where I've made it public.
... It hasn't been announced widely because I wanted feedback here first.
ht: What I've done in this and
the companion document pointed to from it, is do my own
first-hand investigation of a number of the technical issues
surrounding the question of the ARIA vocabulary
... and how it should be integrated into HTML and SVG and other languages.
... And, in particular, to try to produce a cost-benefit analysis of the various options which I believe are or have been proposed.
The proposed mechanisms are used by both authors and user agents.
ht: ARIA faces both ways. If you only understand one thing about ARIA, I would recommend that it be that fact. It's very succinctly explained in section 6.1.
ht quotes the relevant paragraph: "The ARIA roles and properties are conceptually simple enough, but they are designed to provide a bridge between HTML and desktop accessibility APIs, a bridge which is exploited by the operating system, user agent, and assistive technology all working together. There's a complex set of interdependencies there and the feasibility and details of many of the ARIA features could only be worked out by testing in deployed systems, and t
herefore doing early implementation."
ht: It gives authors a semantic
and markup vocabulary for saying what the function of different
bits of screen real estate is.
... The example I pushed on was the case where an author uses some section of screen real estate as a checkbox.
... ARIA gives them a way of saying "this bit of real estate is actually a check box".
... All sorts of things follow from that. If you tab, you'll hit it, if you hit the spacebar, it'll toggle, and that event will propegate.
... All of that is the fundamental semantics/value proposition of ARIA.
... The syntax used is actually a very small corner of the overall project. But of course it's the one that has the greatest impact on document architecture.
... It's crucial to understand that the huge bulk of work done has nothing to do with the syntax.
... This is good news wrt to the question of syntax because the syntax is a small part.
... What I found was that browser performance was much more flexible than previous analysis might have suggested.
... I actually got the FF3b5 beta sources and found that I could change the syntax to use colons in about two hours.
Raman: FF2 had implemented all of
ARIA using namespaces prefixes and colons. That impl was
deleted when Firefox and Opera decided that they wouldn't be
... It wasn't that it was hard to implement, it was implemented and then removed in order to line up with things like Opera.
ht: That's the background to what I've been doing. Now maybe we should focus on the cost-benefit table.
ht: I looked at four options,
... The third option, mixed, is what's in the public draft today. Having said that AFAICT, no one is actually in favor of this approach.
... Use aria- in HTML and HTML5 and use aria: in XHTML and SVG.
... That is not what the browsers currently implement and it's not waht the WAIPF working group are planning on AFAICT.
... What is implemented and what appears to be what they're inclined towards is the "dash" approach.
... And the approach I'm actually inclined towards, use colon and use it everywhere and always spell the properties aria:, has some peculiar properties.
... It turns otu that with the exception of Opera, all of the existing browsers will let you access attributes in namespaces in XML via their full name.
... In fact, that's the way the DOM getAttribute accessor is defined.
Raman: We used to style things in the XForms using the pipe syntax. That used to work.
ht: And it does work in some
... So, I guess I feel a bit like Jonathan at this point. This is not simple stuff. I've introduced it at some length in order to enable people to read it intelligently. And to give feedback and point out gaps.
... I'd like to ask people what time-scale we want to use to proceed forward to try to do something about this.
... The more I've thought about the implemenation issue, the more I'm conviced this is just business as usual. It's great that implementation and spec'ing have been going hand-in-hand.
... So it's perfectly reasonable that the next phase will be more interaction between the spec and the implementors. Just because the implementors have done some work, that doesn't mean they're done.
... If we think there's an alternative, we should pursue it.
Raman: I strongly second that. It would be a giant mistake to treat a first working draft as a candidate recommendation, which is what they're trying to do.
TimBL: Refering to this as a first working draft is demeaning, we know it's the work of years. This is not the first time it's been published.
<dorchard> gotta run..
timbl: At the AC meeting I gave a
talk around this issue. I think if we want them to use the
colon, then we need to work towards accepting that peopel find
namespace onerous and work towards finding shortcuts.
... For example, the namespace document for HTML could say that there are some hardwired prefixes.
<Zakim> noah, you wanted to ask if we are really accounting for problems implementors face
Raman: Yes, if you could get some agreement that aria: maps to the DOM in aparticular way, we'd be done.
Ht: I agree with everything Tim said.
<timbl> if we can hardwarire the prefixes for the text/html type, then we make this smoothly connected between no namespace and full namespace.
Noah: I heard Henry say that the
coding changes in any particular browser to go from where they
are to where w'ed like them be are small. And from that he's
inferring that the barriers are low.
... I just want to point out that the barries to revising a product are not always tied directly to the complexity of the code change.
... My point is that I think it's just more appropriate for us to ask people, rather than tell them, what is or isn't going to be hard.
... Whether or not they can do that may certainlyd epend on other things.
... Having said that, if some group of browser vendors come back and say that it's hard, we have to respect that, even if we want to continue to push for the change.
Timbl: What would be the cost of
changing it in three years time?
... If we develop a lightweight namespaces mechanism, and come back and push hard later, isn't that going to be even harder?
Noah: Right, I think we need to convince them that there's sufficient value to do it anyway, even if it's hard now.
<Zakim> ht, you wanted to correct the use of the word 'product'
Noah: I think the reasons to do this carefully and to keep going are very good as long as we can do it in a way that's respectful.
Ht: Absolutely, Noah, and thank
you for putting that perspective on it.
... If I have a quibble, it's that there are no released products AFAIK that have this code welded into them.
Raman: To balance what Noah is
saying, let's remember that at the last technical plenary in
October people were ringing the bell saying that it was all
... We have to keep in mind how release cycles work; I think as the TAG in terms of long term architecture, we'd be mistaken to develop along those schedules.
<Zakim> ht, you wanted to make the SVG point
Raman: Nine months have gone by and the things that were supposed to be baked aren't. We've come a long way towards having some deeper insight. If the argument now is that we should have said this 9 months ago, remember that they could also say it 9 months from now.
ht: I don't have an attribution
for this, so I didn't put it in the document, but I get the
impression that the SVG community is really unhappy with the
... I think they're the obvious case to lean on for a uniform solution. They're in XML and they already have a story that says it's ok to add new attributes in foreign namespaces anywhere you like.
<noah> Yes, it's also true that there is a long history of various parties claiming "things are locked, I can't change my code", and then later changing it. Sometimes that's due to honest lack of foresight, and sometimes perhaps for less defensible reasons. Still, we need to be at least respectful of the range of difficulties that can be involved in revising mass market software.
ht: They've got what they need already.
Raman: the same thing is true in MathML. The MathML folks are going through huge changes to support HTML5, but they're not happy about it.
Stuart: How far through the discover process do you think you are?
ht: I'm satisfied that I'm done
as far as the technical issues.
... and that I've set them out reasonably clearly. We need feedback on whether or not I'm right.
Stuart: So we're not ready to develop a position?
ht: I'm happy that the people who
have spoken seem to be leaning towards the colon solution, but
I agree that we still need some feedback.
... I'm prepared to publicize this as important input into the TAGs decision.
timbl: So how much endorsement would the TAG like to provide?
ht: No, I think the question is, what more does the TAG want before it makes a recommendation.
Timbl: I think we have to do more than just make a recommendation. We should ask if our experiences have been able to motivate people to believe that colon is better.
Stuart: I'm feeling that we have some obligation to the ARIA community to say where we've gotten to.
ht: One option is to publish this
note with a cover that says the TAG is still exploring this
issue. Further input along those lines is solicited.
... Or we go a step further and say, "our reading of the situation says the colon would be better, does this persuade you?"
Raman: I like the second
approach, but I think WAI PF is the wrong target.
... In some sense, although the draft is written by WAI PF, they aren't really the technical drivers. It's the browser vendors that we need to talk to.
Stuart: So who?
Raman: The HTML 5 list and the
... There would be value in reducing the amount of indirection.
DanC: Mike Smith brought this up in the HTML WG IRC channel and Henry Sivenen looked at it. We could also do this by email.
DanC: The implementors have responded somewhat predictably to the suggestions made by Mike Smith.
ht: Well, at the very least, email has at least a slightly more citable record.
Noah: I think the simple truth
is, I think almost everybody believes that there could be some
incremntal value in distributed extensibility if it could be
... We all agree that there's some kind of cost benefit tradeoff between enabling distributed extensibility vs. not bothering.
... Many of us believe that there's huge value in distributed extensibility and some other members of the community are just not convinced. ARIA are sort of caught in the middle.
timbl: To summarize this problem,
it's a discussion between Anne and Henry. I think we need to
get them together in a bar or something to work it out.
... It would be good if we could get the right folks together on the phone or IRC or email or something.
<noah> I said: I perceive that the Aria folks might be more sympathetic to namespaces if there was near consensus on the HTML and other pertinent communities that distributed extensibility is important. In fact, it's a point of known disagreement between smart people: some of us believe the distribtued extensibility is of compelling value, and others look at it and say "not given the pain it causes sytactically". The Aria folks say: if you can't get better cons
ht: I've forgotten where Anne and Henry Sivonen are.
<Zakim> ht, you wanted to ask a question about the HTML 5 WG
ht: Let me look at the possibility of meeting and maybe something can be done.
ht: But I wanted to ask another question. I know that they're by far the most vocal members of the WG, but do they speak for the WG ?
ht: So I'm back to thinking it
would be useful to talk, but I still wonder whether a
combination of Timbl/Raman's sugestion is the best next
... Publish the document and say, "we're convinced the colon is a viable option, what do you think?”
Raman: It's an objective method
of going forward. The document has new information.
... Given the new state of information, this is the one people will refer to.
... That's the reason I said to publish it widely.
Stuart: is there anyone on the TAG who would be opposed?
Norm: On the contrary!
Stuart: Ok, that seems like a good general direction. We need to formulate that into an action.
<scribe> ACTION-141: Henry S. to circulate the document with a cover note that expresses that the TAG now has a working hypothesis that the colon is technically feasible and invites continuing discussion. [recorded in http://www.w3.org/2008/05/08-tagmem-minutes.html#action01]
ht: I'll circulate it within the TAG before I publish it.
Stuart: I think that's as far as we can go for today.
General agreement that it was very productive.
Raman: I could add more text, but there's been relatively little feedback.
<scribe> ACTION-142: Norman to review Raman's draft of webApplicationState-60 [recorded in http://www.w3.org/2008/05/08-tagmem-minutes.html#action03]
DanC wonders how we get their attention.
Raman: I've already talked to the Google WebToolkit guys. Dojo would be useful. JQuery would be useful. Perhaps circulating it on a couple of other web developer communities would be useful. Maybe HTML5?
DanC: I wonder if they're breakable
<DanC> (found it... http://www.w3.org/2001/tag/doc/hash-in-url )
Raman: If you can access the address bar, you can definitely break them. They've all got state encoded in the hash. You can, for example, read a few articles in Google Reader then monkey with the address bar and you'll get what you get.
<scribe> ACTION-143: Stuart to review Raman's draft of webApplicationState-60 [recorded in http://www.w3.org/2008/05/08-tagmem-minutes.html#action04]
Noah: I see this and I kind of
get it, but then I read the architecture document and try to
understand if it tells a story about this.
... If I read it with some sympathy, I could almost put together a story, but my question is, let's say we decide that we decide this is an OK thing.
... Have we already told the story, or do we need to tell more stories about resources and assignments, etc.
Raman: A lot of these ad hoc
extension have been made by small groups. Our first task should
be to look at all of the idioms and see if we can find where
the conflicts exist and resolve them.
... After we've decided all that, then we'll have a story to tell.
... My bigger concern is that no one has actually bothered to write down any of these idioms, let alone all of them.
Noah: So this is an argumet to
work bottom up. I often prefer to do these things a little bit
from both ends.
... I like to ask, is there an implicit architecture here? There might be some individual stories here that would be useful with respect to URIs and resources.
... Then we can ask if the stories are consistent, philosophically, with web architure. And then we can ask if we need to extend the archtecture or push back and say that this runs but it's still a bad idea.
Raman: Noah, if you have time to articulate some of these higher level questions, I'd be happy to put them in.
<scribe> ACTION-144: Noah to attempt to articulate some of the higher level questions for inclusion in the draft. [recorded in http://www.w3.org/2008/05/08-tagmem-minutes.html#action05]