- From: Norman Walsh <ndw@nwalsh.com>
- Date: Thu, 08 May 2008 14:39:36 -0400
- To: www-tag@w3.org
- Message-ID: <m2abj0y713.fsf@nwalsh.com>
See http://www.w3.org/2001/tag/2008/05/08-minutes
W3C[1]
- DRAFT -
TAG telcon
08 May 2008
Agenda[2]
See also: IRC log[3]
Attendees
Present
Stuart, Norm, Raman, DanC, TimBL, Noah, Dave (partial), Ashok
Regrets
Chair
Stuart
Scribe
Norm
Contents
* Topics
1. Issue httpRedirections-57
2. Issue tagSoupIntegration-54
3. webApplicationState-60
4. Any other business
* Summary of Action Items
----------------------------------------------------------------------
<ht> ScribeNick: ht
SW: Agenda accepted as circulated
... Minutes http://www.w3.org/2001/tag/2008/05/01-minutes[4] approved
... Next meeting 15 May
NW: Regrets for 15 May
SW: jar to scribe 15 May
Issue httpRedirections-57
JR: I've prepared a document
<Stuart> http://sw.neurocommons.org/2008/uniform-access.html[5]
JR: Containing use cases, at DC's request
... 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 case
... 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 manipulation
... 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[6] )
scribe: See the document
http://sw.neurocommons.org/2008/uniform-access.html[7] for details
SW: You would like input on this doc, right?
JR: 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.
<Stuart> http://www.w3.org/2001/tag/2008/05/19-agenda.html[8]
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
Issue tagSoupIntegration-54
<ht> http://www.w3.org/QA/2008/05/syntax_for_aria_costbenefit_an.html[9]
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> http://www.w3.org/XML/2008/04/ARIA-Testing/[10]
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>
http://www.w3.org/QA/2008/05/syntax_for_aria_costbenefit_an.html#impl[11]
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 using namespaces.
... 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>
http://www.w3.org/QA/2008/05/syntax_for_aria_costbenefit_an.html#analysis[12]
ht: I looked at four options, listed alphabetically.
... 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.
... The approach which I canvased in my original exploration which was to
use a colon in the syntax and Javascript and CSS sins to give unform
access is called the "xcolon" 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 browsers today.
... 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 baked.
... 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 aria- story.
... 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 browser vendors.
... 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 free.
... 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 ?
DanC: No.
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 step.
... 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: 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[13]]
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.
webApplicationState-60
Raman: I could add more text, but there's been relatively little feedback.
<scribe> ACTION: Norman to review Raman's draft of webApplicationState-60
[recorded in
http://www.w3.org/2008/05/08-tagmem-minutes.html#action03[14]]
DanC: One place where the rubber hits the road on this is JavaScript
libraries, right?
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[15] )
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: Stuart to review Raman's draft of webApplicationState-60
[recorded in
http://www.w3.org/2008/05/08-tagmem-minutes.html#action04[16]]
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: 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[17]]
Any other business
Adjourned.
Summary of Action Items
[NEW] ACTION: 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[18]]
[NEW] ACTION: 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[19]]
[NEW] ACTION: Norman to review Raman's draft of webApplicationState-60
[recorded in
http://www.w3.org/2008/05/08-tagmem-minutes.html#action03[20]]
[NEW] ACTION: Stuart to review Raman's draft of webApplicationState-60
[recorded in
http://www.w3.org/2008/05/08-tagmem-minutes.html#action04[21]]
[End of minutes]
----------------------------------------------------------------------
[1] http://www.w3.org/
[2] http://www.w3.org/2001/tag/2008/05/08-agenda.html
[3] http://www.w3.org/2008/05/08-tagmem-irc
[4] http://www.w3.org/2001/tag/2008/05/01-minutes
[5] http://sw.neurocommons.org/2008/uniform-access.html
[6] http://www.w3.org/2001/tag/doc/whenToUseGet.html
[7] http://sw.neurocommons.org/2008/uniform-access.html
[8] http://www.w3.org/2001/tag/2008/05/19-agenda.html
[9] http://www.w3.org/QA/2008/05/syntax_for_aria_costbenefit_an.html
[10] http://www.w3.org/XML/2008/04/ARIA-Testing/
[11] http://www.w3.org/QA/2008/05/syntax_for_aria_costbenefit_an.html#impl
[12] http://www.w3.org/QA/2008/05/syntax_for_aria_costbenefit_an.html#analysis
[13] http://www.w3.org/2008/05/08-tagmem-minutes.html#action01
[14] http://www.w3.org/2008/05/08-tagmem-minutes.html#action03
[15] http://www.w3.org/2001/tag/doc/hash-in-url
[16] http://www.w3.org/2008/05/08-tagmem-minutes.html#action04
[17] http://www.w3.org/2008/05/08-tagmem-minutes.html#action05
[18] http://www.w3.org/2008/05/08-tagmem-minutes.html#action01
[19] http://www.w3.org/2008/05/08-tagmem-minutes.html#action05
[20] http://www.w3.org/2008/05/08-tagmem-minutes.html#action03
[21] http://www.w3.org/2008/05/08-tagmem-minutes.html#action04
[22] http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/scribedoc.htm
[23] http://dev.w3.org/cvsweb/2002/scribe/
Minutes formatted by David Booth's scribe.perl[22] version 1.133 (CVS
log[23])
$Date: 2008/05/08 18:37:27 $
Received on Thursday, 8 May 2008 18:40:14 UTC