W3C home > Mailing lists > Public > www-tag@w3.org > May 2008

TAG Minutes 8 May 2008

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 GMT

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