Web API Face to Face 5
25 and 26 Jan 2007

See also: IRC log


Anne van Kesteren (Opera)
Charles McCathieNevile (Opera) - Chaals / CMN
Arun Ranganathan (AOL)
Doug Schepers (6th Sense)
Jim Ley (invited expert)
Travis Leithead (Microsoft)
Dean Jackson (W3C)
Nandini Ramini (SVG Chair)/ JavaGal
Marcos Carceras (WAF)
Fabien Gandon (25th, am)
Rhys Lewis (DIWG chair)(25th, pm)
Dave Raggett (25th, pm)
Aaron Leventhal (P and F)(26th)
IRC (intermittently)
Bjoern Hoehrmann (Invited Expert)
Maciej Stachowiak (Apple)
Ian Hickson (Google)



JibberJim: I am jim and might be connected to Joost

Bjoern is on IRC and is Bjoern

Travis: Just got dumped in the group, work for Dave Massy in IE (Dave regrets that he is still in bed asleep...)

Fabien Gandon: Here because I missed my plane... we are developing a front end to a semweb application and I thought I could sleep here

AvK: Anne van Kesteren, work at Opera, good at naming methods

AR: Arun Ranganathan, AOL AC rep and CD distributor

DS: Doug Schepers, 6th sense. We do software development metrics. I am also in SVG and WAF

CMN: Chaals, from Opera, chair of this group.

NR: Nandini Ramani, chair of SVG, from Sun, also work on JCP and have a graphics hardware background

MC: Marcos observing from WAF group, PhD student at Queensland University of Technology.

JSR liaison request

<chaals> http://www.w3.org/mid/45B63FFF.4050806@sun.com message from Ellen about liaison

NR: Java Certification Requests JSRs 280,287,290 have a huge dependency on Web API (and other groups) as do CDF and SVG WG's

<chaals> NR: There is a big dependency on DOM from all over the place, but in this case the JCP (Java Community Process) is the one most urgent...

NR: JSR 280 (DOM API package) depends on DOM core L2/L3 and DOM EVT L2/L3 Other similar dependencies, but JSR-280 is first. Want to talk about ProgressEvent, MouseWheelEvent - ElementTraversal - Event Groups - REX and Media Access Events

NR: We're waiting on some clarifications:

<bjoern> those proposals should be in http://dev.w3.org/cvsweb/~checkout~/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html except for some mouse wheel prose

NR: initProgressEvent - if the total in unknown, what do you do? Java cares about exceptions

<bjoern> (actually, the .xml version has a few more details than the .html version, but it's done either way)

NR: We're happy with MouseWheel event - it needs to be published
... Can we have a timeline?

<bjoern> Well, as I understand it NR wants to know when we can gurantee that we won't change the interface

<bjoern> as far as I am concerned, that's certainly not before we enter CR

<bjoern> when we enter CR, Q2 2007 perhaps?

<chaals> Ideally, yes...

NR: Some sort of guarantee is needed yes.

<bjoern> I am waiting for the group to come up with the missing features we agreed to put in, like soft keys, long key press events, keypress, ...

NR: JSR 280 plans to be submitted to JCP 2 April, so like to have something before then.

<bjoern> I doubt we'd be in CR by then

<chaals> Apart from those do you have other issues?

CMN: My understanding is we're waiting on some events that were assigned to Maciej and Robin.

<bjoern> chaals, me? I don't think so, no.

CMN: So we need to agree to drop them, or get them written.

AvK: We do feel the keyCode mapping is important to get interop

<bjoern> (well, there is the ecmascript dom binding spec that dom3ev depends on in some way, but I assume that's not too big an issue)

Travis: Are there standard keycodes? defined by Unicode or similar

CMN: You can either use symbols or codes for keys - important for modifier keys and keys

JL: One of the DOM specs does list all of them.

<bjoern> they are not specified

<bjoern> other than that of course

Appendix A, DOM Level 3 - http://www.w3.org/TR/2003/NOTE-DOM-Level-3-Events-20031107/keyset.html

AvK: that's a new feature

<bjoern> these are key identifiers though, not "key codes" as in .keyCode

AvK: keyUp / keyDown / keyPress also differ about what you get
I have an Action Item on this, but it differs across browsers and it's tough to find out

JL: Is there any motivation for fixing keyCode, or just have keyIdentifier

CMN: If browsers agreed to pull it out then replacing would be okay, but otherwise I think we need to fix.

AvK: We could postpone it to a seperate draft

<bjoern> +1

<chaals> if we postpone the key stuff, would that give us a spec going to last call, bjoern?

<anne> we'd have to do another WD first since we added stuff

<schepers> that's fine

<bjoern> well this isn't the only thing

<schepers> what else?

<bjoern> the group also wanted to add e.g. longkeypress, and solve the mobile / soft key issue

<schepers> that's all key stuff

<chaals> Yeah, if we postponed all of those.

<bjoern> if we postpone all open issues, then we're about ready for lc yes

<schepers> so, the only open issues are keycodes, longkeypress, and mobile / soft key issue?

<bjoern> there is also http://www.w3.org/2005/06/tracker/webapi/issues/79 which is kinda related

<bjoern> and the ecmascript dom bindings spec is missing, which shouldn't stop us imo

<chaals> http://www.w3.org/2005/06/tracker/webapi/

<bjoern> Hixie also had some concern about the current mouse wheel event design, I'm not sure I understand his issue though

<schepers> ok, thanks, bjoern... that's also keyboard stuff

<bjoern> but that's about all I can think of, yes

<schepers> CMN: we can take it to LC and he can raise the issue then

AvK: The issue is you can't cancel the horizontal wheel, but can the vertical

CMN: I suggest we strip out the keyboard issues which are holding back DOM 3 events

<trackbot> Created ACTION-226 - Write spec for keyboard stuff [on Doug Schepers - due 2007-02-01].

CMN: DS action is covering longkeypress and all the rest of the keycodes

<chaals> BH, wanna put out a draft ready to propose as last call, given that you don't have to have keyboard things in it?

<trackbot> Created ACTION-227 - Create spec covering keycodes, longkeypress, and mobile / soft key issue [on Doug Schepers - due 2007-02-01].

TL: The use case of pressing two buttons at once isn't important?

<bjoern> I can prepare a new draft early next month; I would suggest to publish that as wd with a short review period and if nothing comes up publish the lc shortly after.

<schepers> bjoern++

<chaals> Great. Let's make that our plan of record.

RESOLUTION: Prepare new draft for publication as a WD next month, and if nothing comes up, LC shortly after

NR: ElementTraversal, like to include it in DOM 3 Core

CMN: In DOM3 core, or just as a spec?

<bjoern> We cannot add new feature to DOM 3 Core, it'd have to be a separate spec or a new DOM Level/version

NR: Just as a spec

<bjoern> note that robin wrote http://dev.w3.org/cvsweb/2006/webapi/ElementTraversal/ some time ago

CMN: We can produce the ElementTraversal spec, if you can give us a Member to help do that.

<bjoern> for the ElementTraversal test suite in particular...

CMN: Find an Editor, and you can have it.

NR: Will find an editor for it.

RESOLUTION: If Nandini gets an editor for ElementTraversal, then someone will be making it happen.

Event Groups

NR We would like event groups. OK, we could live without it if we can have the other stuff


NR: Important thing is to get it out there - I believe it's ready to go

CMN: Allegedly ready for LC
... We don't have an editor for it, and it's not a core deliverable

NR: If it was ready, it could be made to LC

CMN: Would need to get someone to review it, and would be happy if it was a positive one.
... If someone from SVG group or similar did the review, then as Chair I'd be happy to also say yes to LC

ProgressEvent - total

NR: What should total be when it's not known - large number, negative, zero ?

<chaals> http://www.w3.org/2005/06/tracker/webapi/issues/104

CMN: Large number is worst, don't mind 0 or -ve one

NR: -ve sounds slightly more appropriate

<chaals> http://dev.w3.org/cvsweb/2006/webapi/progress/Progress.html

SomeoneWe have made it unsigned, so can be zero but not -1 without a painful change

RESOLUTION: Make the total of a progress event when the total is unknown 0

CMN: Are we happy it's in the NULL namespace?
... We are

RESOLUTION: Editors should clarify the NULL namespace and clean up the text

TL: Just need to make sure Event Spec and Progress spec agree

Progress Event bubbles/cancelable?

<Travis> CMN: Does progress event bubble?

<Travis> NR: Yes it does bubble.

AvK: if we don't bubble we have an increase in performance.

CMN: Does anyone have a use-case for bubbling the progress event?

AvK: meaning that a use-case for bubbling that is not already addressed by the event capturing?

CMN: The progress event will not bubble, but should be cancellable.

DS: What will the "default action" be? Use case: the UA provides a progresss bar, but you don't want to it work--you want to provide your own.

CMN: You want to be able to tell the UA that it didn't notice.

AvK: We need to have a far more complete use case here...

JL: We should be general, so that in some future scenario it may be possible.

AR: it might make sense, if the actual "loading of the event" can be cancelled, then the progress notification should be cancelled--however, if the loading was stopped, then no more notifications of progress would be sent! So...

CMN: the other use case, of preventing the default UA action is probably the most compelling... meaning, it's sufficient to make the event cancellable.

<Travis> CMN: Switching over to File upload...

DS: If you hit the stop button, does the XHR stop too?

JL: Testing would be very interesting if progress events could be sent for synchronous XHR... Stop would just stop the XHR... The use case here is that you might like to see the progress of something being uploaded, then being downloaded.

AvK: for <input type=file> this is just a ProgressEvent, rather than just a general progress.

CMN: We have to have this upload progress for file upload.

AvK: [looking at the spec] we have preload, postload (mentioned in the current draft). We have to ensure that UA's fire the correct progress event type. there's no need for a 'stop' because 'load' fires when its done and 'start' is implicitly the first event fired...

DS: seems sensible.

CMN: ...When the loading starts (the first progress event fires), it may tell you the total size of the thing going up or down. Use case: grab the first progress event, use the total to set up the progress bar size...

AvK: You just need to know how much to fill the progress bar

CMN: We should ask the SVG implementors why they added 'start' /'stop' and see if we can remove them.

AvK: lengthComputable should be dropped, because total is 0...

RESOLUTION: Drop lengthComputable

<trackbot> Created ACTION-228 - Ask SVG implementors if they have any problem with us simplifying progress event types [on Charles Mccathienevile - due 2007-02-01].

DS: checking for any more action items on ProgressEvent...

NR: When is this going to get published?

CMN: We're trying to publish this as soon as we can

<anne> http://lists.w3.org/Archives/Public/public-webapi/2006May/0000

AvK: Some descriptive text will need to be added to clarify some properties..

CMN: Do we care about knowing something that is zero size, or something that is unknown? It's a fairly degenerate case when you get a 0 length transfer, and you're still waiting for a progress event--it doesn't make sense... If total is zero, then 1) you're transferring a zero length [something], and 'load' will follow... So, we don't need lengthComputable.

AvK: total is zero if it's not known; lengthComputable is dropped, and rename loadprogress to progress?

CMN: Seems like: 'uploadprogress' and 'progress' Implementors should be queried, and we should try to stick with their names...

DS: I don't know how widely deployed these names have been in existing implementations.

CMN: We'll see of implementors object, and we'll take it from there. Any more issues for ProgressEvent?

RESOLUTION:drop start and end event types, add uploadprogress, rename loadprogress to progress

NR: Is there a date for this then?

CMN: This week I will try to publish a revised edition, and perhaps LC by mid-feb (perhaps a bit optimistic).

SelectorsAPI specification

<anne> http://dev.w3.org/cvsweb/~checkout~/2006/webapi/selectors-api/Overview.html?content-type=text/html;%20charset=utf-8

Travis: get doesn't give me anything, I don't know what this method does

Avk: you need this with the DOM it is convenient
... macth and matchAll may be were better

Travis: just concerned by the length of the name?

Avk: yes

<bjoern> my 2 EUR on that: http://lists.w3.org/Archives/Public/public-webapi/2006Dec/0098

DS: long name can be aliased and will be

AR: you can alias but you shouldn't have to depend on alias

Charles: long names make sense to me ... even when they are a pain to type.

DS: e.g. nodeListBySelector for matchAll

AVK: a correct name would be getElementByGroupOfSelector

Travis: let's look at the issue of returning an element vs. a set of elements

AVK: getElement and getElementList

Travis: you missed the "s" : getElementByGroupOfSelectors

<marcos> object.getElementBySelectors("#fdsdsf");

<marcos> object.match("#fdsdsf");

<chaals> document.getElementListBySelectors(".extension")

<marcos> object.matchAll("#woop")

<bjoern> o.cssQuery('#woop')

DS: synonym for selector?

Marcos: "match"

Travis: match doesn't give you an idea of what is matched.

Marcos: the argument is what specifies what is matched

Travis: clarity and consistency vs. what already exists

Charles: the argument is not enough, you don't see what the method does for you.
... "get" is much clearer

AR: what about the additional S at the end?
... ElementList is not a real structure it is just a plural.

<chaals> so getElementBySelector and getNodeListBySelector ?

JL: in the future we may have methods returning text nodes

<bjoern> not via CSS Selectors.

<marcos> getTheListOfElmementByTheSelectorAsDefinedInTheSelectorSpec()

<bjoern> selectNodes and selectSingleNode (XPath) do this

<anne> http://www.w3.org/TR/DOM-Level-3-Core/core.html

Travis: if it retuens a Node List it will be confusing (really is a not live list of element)

DS: what about getListBySelector(...)

AR: what about defining List as a real structure.
... what about a straw poll?

Charles: we rule "match" out? [we do]
... we have "get" and "getAll"
... current proposals getElementBySelector getNodeListBySelector getElementListBySelector

Travis: selector plural or singular is fine.

AVK: a concrete counter proposal must replace everything which is removed.

DS: getElementBySelectors for the first thing that matches any of these selectors (1+)

Travis: getAllElementsBySelectors returns a node list of all ellements matching any of these selectors (1+)

Charles: getListBySelectors is shorter but not short enough to be justified so... discarded.

<schepers> [more discussion about names]

<bjoern> I am +1 on http://lists.w3.org/Archives/Public/public-webapi/2006Dec/0098 ...

AR: getStaticNodeListBySelectors would be exact naming but we don't want that.

Charles: we are left with getElementBySelectors and getElementListBySelectors

DS: ok but they are not short enough but they are descriptive

Charles: in the absence of consensus on other proposals the issue is resolved

AR: I want to hear from the mailing-list if there is an alternative to getElementListBySelectors or someone defines ElementList.

<trackbot> Created ACTION-229 - Update and publish the editor draft and request feedback for the mailing-list [on Anne van Kesteren - due 2007-02-01].

RESOLUTION: The names will be getElementBySelectors and getElementListBySelectors

Meeting is adjourned for lunch - start again at 2H30 PM

<chaals> Rhys presents a bit of what UWA is about...

timelines and deliverables

<chaals> http://www.w3.org/2006/webapi/group/timeline - an interesting work of fiction

Charles: XHR, could be last call since november.

AvK: I suggest we have a review period of 3 weeks to 1 month.

Charles: Hey, it is Australia Day. Time off for me and Marcos

RESOLUTION: Request transition of XHR to be last call for a period of 1 month from when it gets published

Charles: this will hopefully happen next week. Need to talk to dino

Charles: XHR2

AvK: xhr2 will add new events and so on. and it will relate to ProgressEvents.

Charles: any idea when a first draft might be coming

AvK: after a month or two, depends on the Access-control document

AvKWindow is hard to define it because it is so closely related to the HTML

AvK: should we make this timeline public

Charles: I'm ok with that

RESOLUTION: publish the timeline in public list

<trackbot> Created ACTION-230 - Publish the timeline to the public [on Charles Mccathienevile - due 2007-02-01].

Charles: DOM3 Core - need to ask bjoern

Charles: DOM 3 Events needs to be published as a WD, so we can ask for Last call on it soon.

Charles: Chaals: ECMAScript bindings for DOM has no editor

Charles: Network. We are currently editing that, and chaals and gorm are looking to have a draft by feb. (Gorm does the technical bit, I am going to do the admin stuff for the document and publish it).

Charles: Chaals: Persistent Storage, DOM 3 XPath: they both need an editor

AvK: lots of work has been done on persistent storage, by mozilla an WhatWG

Charles: Drag and drop is going a bit slow, it would be nice to have a last call by september

<Hixie> (isn't drag-and-drop just a matter of copying and pasting the whatwg text?)

<anne> (I think so)

Charles: Chaals: Progress Events last call by end of feb

Charles: Chaals: File Upload...

AR: it is at an early stage

Charles: REX is waiting for an editor

Charles: Selectors API to be published as working draft "now".

<trackbot> Created ACTION-231 - Publish Selectors API [on Dean Jackson - due 2007-02-01].

Charles: hopefully we will have a Last Call by sometime in feb

Charles: Element Traversal...

Charles: I like the idea, but I'm not sure if I want to edit it

<chaals> File Upload...[ assorted unminuted discussion of file upload...revolving around security issues, the suggestion that it should be based on HTML input type="file" (or not), and what happens when people can replicate file upload boxes.]

<chaals> Orphan specs:

<chaals> DOM 3 Xpath, Persistent Storage, apparently Window

<chaals> and things that we don't *have* to do according to our charter: Element Traversal, REX (both of these are waiting for love from the SVG/JCP people who want them so soon)

<chaals> and ECMAScript bindings for DOM (just plain orphaned with no friendly aunt on the horizon)

Charles: all these orphan specs... any takers?

TL: I might take one.. I will let the group know

Charles: persistant storage will probably be a smaller job than window. How about Jim does window

<Hixie> Window will be a huge job

<anne> so many weird quirks

JL: I'll be happy to do it

<anne> (in XHR, Window prolly too)

<Hixie> (i'm actually not convinced you can do Window outside of HTML)

<anne> you should be able to implement it outside of HTML...

<Hixie> not really sure how

<Hixie> it embeds so tightly with HTMLDocument

<Hixie> and with navigation in general

<anne> but navigation isn't HTML specific...

<Hixie> anne: well, if Window is in its own spec, which spec is going to define how you do content sniffing when you do window.location.replace()?

<anne> Hixie, well, HTML could define how loading a resource works

<Hixie> (can't rename that interface for back compat reasons, imho)

<Hixie> anne: resource loading is very tightly bound to the updating of properties on the Window object during history navigation

<anne> (fair enough)

<anne> hmm, painful

<Hixie> see http://whatwg.org/specs/web-apps/current-work/#navigating and http://whatwg.org/specs/web-apps/current-work/#history

<Hixie> it's also very tightly defined with JS' global scope

<bjoern> test suite...

<chaals> indeed...

<anne> bjoern, well in theory someone else should do that

<anne> for XHR it was useful that I wrote one while writing the spec

Charles: as bjoern mentioned, test suites are important... anyone keen to write a test suite? I have someone to do the test suites for Progress Events and Drag and Drop

AvK: I've produced a test suite for XHR... and did some testing on window

<anne> (The test suite for XHR is non-comprehensive fwiw.)

AvK: progress events are difficult to test. The test suite needs to be developed closely with other specs like XHR. it's best that the editor is not involved in designing the test suite

<javaGal> +1

<anne> http://tc.labs.opera.com/apis/XMLHttpRequest/

<anne> http://tc.labs.opera.com/html/

<chaals> mjs, current plan is to hand Window to JibberJim 'cause it seems you are busy...

<chaals> Do you have any tests for specs that you can share (or someone with lots of time wanting to produce same)?

<JibberJim> mjs, of course if you'd rather keep ownership...

<chaals> ?

<mjs> I'd love to have JibberJim's help if he's willing to be co-editor and if we have general agreement on the right direction for the spec

<mjs> JibberJim: do we have general agreement? I know we disagree on a bunch of things, but I don't know if the contents and style of the Window spec are among them

<JibberJim> I thought we pretty much agreed on that last time

<mjs> let's discuss briefly and find out

<mjs> my basic thoughts on the Window spec:

<mjs> - other than current contents, the main missing features are timers and details of the language binding, otherwise nothing really needs to be added

<mjs> - in terms of spec lawyering detail, the main thing that needs fixing is updating the Location object properties to be defined in terms of the latest relevant URI RFCs

<mjs> - timers should be written using nominally language-independent IDL, but with special conversion rules for JavaScript so you can just pass function objects or srings to be eval'd

<mjs> - language bindings should be normative and defined w/ very clear conformance requirements for implementations, including details for JS of what to do for wrong types, what properties should be shadowed, etc

<JibberJim> I don't think we disagree there

<JibberJim> we might disagree on what to do with wrong types etc.

<mjs> well, I think what to do with wrong types should be determined by testing what existing implementations do

<JibberJim> then we won't disagree :)

<mjs> primarily MSIE, Firefox, Safari, Opera

<JibberJim> So if you're happy to have me help - we should set up some time to go through what needs doing and divide the work up?

<mjs> sure

<mjs> the four biggest work items are timers, updating Location stuff to latest RFC, JS bindings and Java bindings

<anne> Location stuff should also be made reusable for other specs

<mjs> anne: how so?

<Hixie> HTMLAnchorElement has a bunch of similar APIs

<mjs> ah

<Hixie> would be nice to define them in the same place

<mjs> it's really a pretty crappy API

<mjs> but I will keep that in mind

<Hixie> you'll get no argument from me there

<Hixie> but it's in active use

<Hixie> so...

<mjs> basically the idea of replacing the URL by pieces is silly for many of the available pieces

<mjs> doesn't really do anything you couldn't do w/ relative URLs

<Hixie> again, totally no argument from me

<Hixie> the Web provides a compelling counter argument, however

<mjs> I'm not saying anyone should change it

<mjs> this is just my token complaint

<mjs> sometimes one's mind rebels slightly at speccing out things that are unconscionably bad albeit widely used

Adjourned for the day

EXI joint meeting

<chaals> In the EXI room - a presentation on EXI followed by discussion.

<chaals> use a schema to get a rough idea of the thing you are encoding, to optimise...

<chaals> Questions for WebAPI?

<chaals> APIs - want to have information about schemas,; also for XHR encoing stuff on the fly. particularly relevant for small fragments due to the way the optimisation works

<chaals> Data models - Can EXI encode HTML?; REX - EXI supports document fragments. Will those be the same?

AR: XHR and schema could be prblematic. And XHR is not used much for XML. What's the use case for schema?

SW: You use the schema to get an idea of what the content looks like, so you have a better idea of how to compact...

John: You don't have to use schema, but if you have it then it can help you. It isn't a strict contract, it's hints

AR: So you would want to see browsers understand EXI so they coul use it for XHR (etc)

John: Right. They could encode anything, but you can build in knowledge for common stuff e.g. html, svg, ...

DS: Are schemas stored on receiving device?

SW: Internal representation has to be shared at each end. Either because you know a priori, or because you share dynamically

John: Either schema is deployed (for common stuff) on the phone already, or for shiny new stuff we add an API for dealing with teh schema.

DS: Support for mixed namespaces?

John: Yes.

DS: So is there a win where you have mixed-namespace random content? Some along aschema some not?

John: Yes. You can ynamically collect moreschemas for things that appear later...

DV: Even with partial schema you do get an improvement in transmission.

DS: How would things like getElementByTagName work?

John: Through the API you get something that looks like the original document?

AvK: Are there restrictions on characters that can be used?

answer: not really

AvK: Should be possible to do in XHR - question is how to post EXI content?

John: Should be feasible

[discussion on the details]

PLH: Not so convinced - you cannot conneg on a POST

John: Yes, but you can use OPTIONS method to negotiate first.

PLH, AvK capitulate unconditionally and are driven into servitude... (more or less)

AR: True, but not enough yet... from WebAPI we don't yet have enough of a stack for this.

DS: What do you need from us, when?

John: Some user gesture to turn on/off EXI ...

SW: We should have a bit of follow on. You need to know more than just about EXI - there is also a potential to ask what schemas you know

John: Yeah, which is another piece on top (it is more complex than the schemaless case)

Kimmo: Any time last week is good. But we are aiming for First Public Draft in early March, Last Call in summer.

GW: Most of the questions will not be in the FPWD, but in stuff for the end of the year...

DS: Getting a tutorial and so on would help...

GW: Right. Giving everyone a pony would be good PR too...

<anne> so what are the questions?

<anne> HTML, XML -> works

<anne> schemas -> hah

<anne> REX -> hah

<anne> XHR -> works

<anne> APIs -> maybe

<arun> Anne, what do you mean XHR works?

<arun> in conjunction with EXI?

<anne> yeah

PLH: EXI didn't define media type, justtransfer encoding. Does WebAPI have a mechanism for controlling one or other of those.

<arun> I'm not sure that mere content negotiation is sufficient. once you get responseXML, you can't do anything with it unless ua understand the format. which it probably won't.

JL: You can set the header for content-encoding...

PLH: What if the encoding is not supported?

AvK: Nothing works, at the moment... you request something you can't deal with.

SW: Do you do RDF in WebAPI?

CMN: CMN: Not really. There was an idea to do it but we don't have any resources for it at the moment. RDF group are interested, maybe. How would you do Efficient RDF?

SW: Would potentially be worth making a special schema for it in the future. Not our priority at the moment.

John: We handle, in principle, any kind of grammar

Travis: Do you support non-well-formed XML?

John: in principle it can be done

PLH: There are a couple of things explicitly supported already

AvK: So you could already support HTML - DOM <-> EXI, without real loss

<chaals> [discussion about terminology]

SPG: EXI is also interesting in that it allows you to send native binary content. It might be intersting to see if there is something we could do with DOM to handle that...

John: Good point. Typed APIs could be interesting

DS: SVG path element has a really obtuse micro-syntax that could handle some compression ... we allow people to normalise stuff. It might be good to look at compressing that in a regular way ... suspect SVG might be one of the few formats that has their own microformat...

CMN: And all the microformats out there in the world

John: Also comes up in customer land a lot. once you define a type (such as this) you can do that. [chasing out ideas about how EXI might make the microformat things like path more interesting to be represeted as real XML]

<chaals> break time.

New Staff Contact

DJ: I resigned from W3C. You'll have a new contact in a month or so.
... My departure is 95% certain

Meeting times/dates

CMN: Notes that WAF is meeting in April - Brisbane, AU
... A few people will be there - including Cameron, Anne.
... I'd like to meet in Australia.
... What do other people think?

<Travis> I believe that I could participate in Austrailia--though I could loose some sleep over it...

CMN: I'd like to meet before WAF rather than after.

DS: Might be tough for me.

JL: I hope to be able to come - possibly depends on who is paying the bill.

NR: I might be able to attend.

AR: It's possible for me. Lots of other factors to consider - like workload and visas.
... Maybe someone else from AOL could attend.

TL: When would the next meeting be?

CMN: We're planning for 3 or 4 this year
... We'll have to start talking on the phone also.

DJ: I suggest checked where people will attend. It could be Europe, Australia, USA, etc.

CMN: We could host in Oslo. Or Germany so Bjoern could attend.
... I'm planning that we attend the Technical Plenary in Boston, November.

<chaals> bjoern, if we have a meeting near you, is there a good time that you expect to be available between now and september?

<bjoern> I am not here during the games convention, other than that I don't have plans for 2007 yet

<bjoern> end of august apparently

<bjoern> like 22-26 or so

<chaals> oki, let's avoid those dates for a face to face where we hope you can attend

Accessibility for APIs - ARIA

CMN: We have a few accessibility issues - like how to make mouse stuff accessible.

AL: Like scrollwheels, such as don't make it necessary to use the scrollwheel.
... I think it is the job of the operating environment to handle this.
... If elements and widgets could expose that they are a drag target and a drag source then the environment could expose functionality.

<anne> * notes there's a "draggable" attribute in HTML5...

<anne> (and in IE, Safari)

TL: Are you talking about rules for dragging - like point here and hold?

AL: No. Just that the environment should take care of this.
... Do you intend to allow drag from the desktop into a web app?

CMN: Not at the moment.
... It's outside our scope at the moment.
... This doesn't mean we don't have it in mind. It's not a requirement, but we're thinking of it.

AR: Maybe it is the environment's requirement to integrate with the Web spec.

AvK: Things like context menus seem more appropriate to a language like HTML5.

AL: We want the assistive technology to be able to access the APIs.
... With new Web 2.0 the assistive technologies know when things have changed, but don't know if the change is important enough to notify the user.
... We've addressed some of this stuff in ARIA

<anne> http://www.w3.org/TR/xbl/#the-eventxbl

AL: I want to be able to work out what caused a change in the DOM, and then query why the change was made.

TL: This would be useful to security - able to distinguish between user initiated requests rather than script initiated.

AL: I want to know the fundamental event that created the change.

DJ: What is being proposed?

AL: Think about this. I'll get a proprietary API working to show that it is useful.
... If that works then I'll bring it up to you.

CMN: This sounds like Events, which is close to last call.

AL: Within a year or so is ok.

CMN: Please review the events spec and suggest where you think it would fit in.
... We have no plan to do Events 4 yet.

[group discusses ARIA and adoption]

AL: I think many of the things in ARIA will inform the HTML specification.
... At the moment it is a long way in front of HTML.
... We've had many UI controls in the desktop world for years that are not available in HTML, and hence are done with JS and are less accessible.

AvK: It takes a long time to get interoperability.

<aaronlev> http://developer.mozilla.org/en/docs/Accessible_DHTML

AL: Here are some examples. They should degrade in browsers that don't support it.

DS: We should look at how to get something like this in SVG.

AL: We looked at this and discovered that we need to define a lot of new roles, relationships, etc.

DJ: So the action for this group is to keep your work in mind?

AL: Yes. THe P&F group might not be tracking your work on the DOM so much.
... Even by publicizing this stuff we make things better.

<aaronlev> http://developer.mozilla.org/en/docs/Key-navigable_custom_DHTML_widgets

AL: We publish some tips and tricks for interoperability.

sshhh. darobin is here.

<chaals> lunchtime.

Element Traversal

<schepers> http://dev.w3.org/cvsweb/2006/webapi/ElementTraversal/source/ElementTraversal.xml?r1=1.1

<schepers> AVK: conformance req should be in intro; intro needs work; needs examples and, for example, text; refs should have a note that it would be filled in later; or RFC2119 and relationships should be dropped or put in the intro; acknowledge me, says anne

<anne> and the only conformance term you need here is "must"

Summary of Action Items

Minutes formatted by David Booth's scribe.perl version 1.127 (CVS log)
$Date: 2007/01/25 22:35:58 $