note: take this list with a grain of salt; roll call was a bit messy
DanC: i will be your chair today;
Chris Wilson will be joining soon
... anything you say will be recorded (or may be recorded) for posterity in public web space
<chaals> scribe: Gregory
DanC: Tim Berners-Lee and John Boyer invited guests
DanC: I incorporated most comments received so far into the agenda; any further comments?
JB: I'd like the forms item discussed early in the meeting.
<DanC> Proposal to Adopt HTML5
DanC: the proposal says "HTML5, comprising the Web Apps 1.0 and Web Forms 2.0 specifications"
<DanC> Here's Web Forms 2.0 ...
DanC: Barstow wrote, 9 March,
seeking confirmation that this WG will "take over" Web Forms
2.0. Dave Raggett had some suggestions for the forms task
Matt: would like clarification as to what is going on with XForms transitional; my understanding is not technically a working draft, but is specifically mentioned in HTML WG charter
<DanC> (indeed... "XForms Transitional" -- http://www.w3.org/2007/03/HTML-WG-charter.html )
JB: basic idea is not a WD at this point; look at what XForms currently provides and what HTML5 currently provides; address ease of use inherent in XForms 2.0; want best of both worlds
DanC: comments are welcome on XForms Transitional, right? seems like it should be a working draft.
JB: first public working draft should appear in June 2007
Matt: I made some comments on XForms Transitional to public-html; have yet to get anything back
DougS: might be good if established what we are discussing; 1) Web Forms 2.0
DanC: indeed; that's the question. Web Forms 2, XHTML tranistional, and other ideas are under discussion.
DougS: will HTML WG take
... as a task force or part of main activity
<John_Boyer> The HTML WG and the 28Forms Working Group <http://www.w3.org/MarkUp/Forms/Group/> will work together in this Task Force to ensure that the new HTML forms and the new XForms Transitional have architectural consistency and that document authors can transition between them
<John_Boyer> from charter
DanC: will be a task force. combining the is the goal.
Matt: convergence of Web Forms 2 and XForms Transitional?
<DanC> (if folks could use , for direct address and : for attribution, I'd appreciate it. e.g. s/mjs:/mjs,/)
JB: yes; XForms transitional maps to XForms; forms WG looking at how to make XForms easier to author; XForms has good bit on this, Web Forms 2 needs author direction
<Preston> @ Boyer - the link you gave is not generally accessible.
?: Is it possible to have some features in HTML that don't find their way into XForms? e.g. things that are specific to HTML because don't fit into XForms.
JB: common tag set and vocabulary essential; whether expressed with well formed XML or tag soup, have same syntax, grammar, and concepts
<mikko_honkala> got dropped
MJS: forms task force goal as stated in HTML charter is not necessarily to ensure the HTML forms and XForms have same grammar and syntax; it's architectural consistency; I prefer to keep forms functionality in the main HTML spec and to have the task force give input to that
JB: trying to create common set of ideas indicated by common tag set; if look at doc source transition between the 2 straightfoward; key issue for document authors
<DanC> task survey results
DanC: John and I have been
thinking about starting the task force; I had the ball and
didn't carry it as far as I was supposed to, but we do have
have an HTML WG task survey; one of the tasks there is the
forms task force (3 people already indicated interest)
... I might extend the deadline on that survey
HenriS: I agree with mjs; forms should be in spec itself rather than seperate spec; Web Forms 2.0 is implementable, but but XForms Transitional is not an interoperably implementable spec; issues raised on mailing list but no solution or resolution; problemmatic that doesn't seem implementable
<anne5> (Besides the native implementation in Opera, there are also several libraries, a testsuite and a conformance checker.)
DanC: are you aware fo the XForms Transitional implementation work by Dave Raggett?
Lachy: why is it a goal to make Web Forms more like XForms? doesn't make sense; XForms doesn't read like a spec; starting over with new spec would be a mistake; changes to Web Forms 2.0 on point-by-point basis
<Hixie> certainly all feedback on the wf2 spec should be taken into account, especially from forms experts like the xforms wg
DougS: task force should be open to entire HTML WG; how will it work?
DanC: it's a joint task force
between the 2 WGs
... I'm not sure crossposting to all 300 HTML WG members is the way to go; I hope we'll form smaller groups around tasks like forms.
JB: trying to do with XForms transitional is to leave it open for new people to define and refine what it states; don't want Web Forms 2.0 to be basis of document until WG has identified things that are likely to change
DanC: to clarify: the HTML5
proposal is not to publish it as a W3C Working Draft, but to
use it as basis of discussion
... I expect requirements and design principles is what we'll deliver for the June deadline.
?: why rationalization necessary? trying to leverage the 7 or so years of experience that forms WG has had to address most complex forms problems; architecture in place that is very powerful; want to pull back to investigate how to make document authoring easier; solving more complicated problems being encounted now with HTML4 forms
Matt: wondering if specific reason why first draft of XForms transitional can't be expressed as delta document? incorportate Web Forms 2 so don't have to reinvent the wheel
DanC: that's a good question, but it's awkward for today, as I scheduled this meeting at a time when Dave Raggett had a previous engagement.
JB: next document should have as
much flow-in from useable material from whatever source;
charter of HTML WG references XForms; task force will be
reviewing and mapping and pulling in things from DaveR's bag of
... need a couple of editors -- forms WG participant and HTML WG pariticipant co-editors, gatekeepers put concepts and ideas before HTML WG and if WG happy with that, then procede
... chairs need to identify who will do this; too many editors a problem, as is too few
DanC: one possible mechanism to collect names of interested people is the existing task survey. I could send a specific message focussed on that task.
JB: I don't seem to be authorized to read that survey
DanC: odd. I wonder where the bug is.
<DanC> ACTION: DanC to call for forms tf volunteers (with review from John B.) [recorded in http://www.w3.org/2007/04/26-html-wg-minutes.html#action01]
DanC: trying to move on to other topics...
JB: appreciate change in agenda to accomodate me
Anne: would make sense if XForms WG were to point out where Web Forms is lacking
DanC: let's not put the burden all in one place; we're in this together;
Anne: Web Forms 2 has taken a lot of XForms transitional into account - what isn't solved by Web Forms 2?
DanC: good question to ask, but we can't demand an answer
<anne5> Nesting of repetition is addressed though...
if look at repeating as example, easy to build list of items;
help if repeating structure had a consistent behavior when try
to nest it; at least 2 level nesting VERY important to get
... there are examples of nesting for Web Forms 2 - best to post specific use case / scenario where you think things are lacking
HenriS: vision for XForms Trans for non-professional authors; server-side portion - can such a product be made before standardization?
JB: don't think that's true - can talk about why you think that
[scribe caught only part of a comment about how XForms Transitional attributes seem to be the same as WF2, but not enough definition to ascertain if the same ...]
MJS: I think the most useful way to express XForms Transitional would be as a set of change requests relative to Web Forms 2 w/ use case justifications
<John_Boyer> JB: The best approach might actually be to identify the use cases, then adopt WF2 or XForms or hybrid solutions as they become apparent based on the use cases
dbaron: architectural consistency is usually an argument when 1 group of people trying to make another group implement something; using W3C forces browser venders to implement XForms; if you don that they'll just leave
<hyatt> agreed with dbaron
<hsivonen> my point was that the product vision for XForms Transitional should be demonstrated in a non-standard product before trying to standardize authoring-product interop
<dbaron> an argument on either side of the debate
DanC: W3C process has WGs
publishing every 3 months; useful; HTML5 spec on our agenda -
interesting, but small miracle to get published as WD in
... meanwhile, I've seen work on design principles; e.g. "don't break the web"
... design principles are an attempt to capture values of community, but don't tend to be hard-and-fast measurable things;
... in contrast, "tree shaped dom" is a measurable requirement.
... one good outcome of having requirements is to abstract away from design details to allow those not directly participating in this group to negotiate at a higher level
... about our charter: W3C strives for consensus, but in this case didn't get it. We made a WG anyway; if you're not happy about charter, there is a long line before you
... one thing that fell on the "cutting room floor" in the chartering discussion is a market threshold - this WG can set it as requirement
MJS: anyone who disagrees with one of the design principles so far
Murray: disagree with one; related to semantic markup and effectively deprecating presentational markup
<DanC> looking at http://esw.w3.org/topic/HTML/ProposedDesignPrinciples
MJS: that's been changed; the closest thing is now "Maciej: separation of concerns": spec should enable the seperation; does not require; specifically states that some presentational markup be retained
<glazou> I hear what mjs said but I'm with Murray here
DanC: could say "look thing is stablized; will give WG x amount of time to review"
<anne5> it's a wiki
Murray: think i would appreciate if have a designated activity with goal and deadline for producing such a document; should be an open process; if opinions in conflict, need to incorporate and synthesize down to what can be agreed upon
<hyatt> 300 people aren't going to agree on much of anything :)
<Hixie> there's no way we'll _ever_ have everyone agree on everything in a group this size
<glazou> hyatt, unless you suggest a beer
DanC: My favorite way for WG
members to volunteer is by starting to do some work.
... everyone has been allowed to do anything;
... process now ad hoc, here to talk about making it more formal
... People who do work should have a fair bit of say over how it is done
<hsivonen> the point of design principles is to document what we decided on points where there *is* likely to be disagreement
David_D: there are prescriptive
and descriptive principles -- prescriptive: here are principles
you should believe in
... if dissent on set of principles group expected to abide by, then group discohesive
<Hixie> in a group this size there will _always_ be dissent, the whole point of these principles is to set the line for where people _will_ disagree
DanC: sometimes it's useful to keep watering down until everyone agrees, but sometimes it's better to proceed despite less than full consensus. For purpose of discussion, pick a principle you don't agree with?
David_D: "don't reinvent the wheel" -- don't agree; tends to stifle innovation
DanC: this WG is not really doing innovation; we're doing standards work
David_D: a lot of new stuff has already been proposed
DanC: I expect any new stuff to go through a lot of trial by fire; mostly outside of this working group
DougS: looked through design principles again; in past thought some very vague; looking through them, don't actually have an understanding of where we are; problem with adopting now is how do we test them? wiki documents or official documents
DanC: they can be a tool to expedite work
DougS: not all of them are clear
in what the implications of them are
... like an i ching or tarot card deck - whatever you see in it is what you belive
<hyatt> i think don't break the web is pretty obvious
ChrisW: recent discussion shows "don't break the web" means a thousand things to a thousand people
DanC: David Baron elaborated on "don't break the web" in a way that was useful to me; the 2 paragraphs that are left don't help as much.
ChrisW: don't break the web as a
browser means when deploy new browser, don't disturb systems or
ecosystems already extant; need to keep errors in it otherwise
infuriate web authors; many are ignorant of specs and
reflexively blame browser (Chris' interpretation);
... alternate interpretation: don't have a revolution that overturns what has worked in the past; easier to progressively deploy UAs; with XHTML required all UAs be able to accept a different mime-type; IE6 didn't support that mime-type; ended up with server side multiple delivery options to support XHTML;
<hyatt> agree with chrisw
Dan: point of order: did I set any expecatations about telcon duration? [after collecting some advice] let's aim for 30 more minutes; 90 minutes total.
MJS: 2 things - tried to document
any principles where there is disagreement - that's why there
is a disputed section;
... in some cases, we'll have to make decision as group; can't have things both ways;
... called for current version to be adopted so that everyone working off same document; if make W3C note, there will be an official standard procedure to make comments, objections, etc.; if want more consensus, putting it up as a W3C note would be good
<schepers> if "Don't break the Web" is put in the disputed category, I'll rescind my objection
<Zakim> timbl, you wanted to suggest that the point of adopting them is the value of the journey: that in discussing them, disagreements and lacks of understanding may be removed from the
TimBL: questions about design principles of web architecture is one of the reasons the TAG was formed
TBL: design principles very hairy; TAG trying to determine what makes web work and what breaks it; journey of arriving on consensus valuable; have whole group in on discussion, creates common vocabulary and trust in one another; part of formation of group; hope for web was that all this discussion would happen via pointers; ease of work internally important
Murray: versioning - decision has
to be made; example of decision made by WG rather than a
document that discussed principles
... document that discusses principles should be a basket of low-hanging fruit. I thought about extrapolating principles from the Web Architecture Document and applied to HTML;
... in the case of disput, it might be interesting for concerted statement to be made, but if too large a number of objectors, weakens the spec; need something that everyone can point to and work towards
... if find significant disagreement, have to remove them from requirements
DanC: one tactic that has worked:
get 2 reviewers and see what happens after a week
... another tactic is to go "around the table" but we don't have time to do that with 27 people here.
<Hixie> 27 is too few, given the size of our group, not too many :-)
DanC: I can think of a couple
options... I'll take advice by doing a poll...
... choice A: mostly comfortable with what is there now; choice B: reviewers lead discussion in group; C) neither
<DanC> A: recruit 2 reviewers; largely delegate to them.
<DanC> B: recruit 2 reviewers; then talk more
<DanC> C: none of the above
<schepers> I think the reviewers should be people not involved in writing the document
<Hixie> shouldn't we also let people who aren't on the call be able to decide this?
<DanC> hixie, we're not making a technical decision
<DanC> just thinking about how to use email etc.
<DanC> MM B
B = 15
<chaals> B above A by small margin
DanC: we would need almost all
A's to go that way.
... offers for review?
DougS: would like to define role what is formal review process
DanC: one email that says "i'm done reviewing" and "thumbs-up" or "thumbs-down" plus anything else you want to add. by Monday is fine.
<DanC> ACTION: IanH to review http://esw.w3.org/topic/HTML/ProposedDesignPrinciples and advise the WG on whether to publish for community review, or whether critical problems remain [recorded in http://www.w3.org/2007/04/26-html-wg-minutes.html#action02]
<DanC> ACTION: DougS to review http://esw.w3.org/topic/HTML/ProposedDesignPrinciples and advise the WG on whether to publish for community review, or whether critical problems remain [recorded in http://www.w3.org/2007/04/26-html-wg-minutes.html#action03]
DanC: everyone else can play along, of course
<Hixie> it'll be done within the hour
<gavin> we lost zakim
MJS: if reviewers make comments requesting editorial or substantive changes, should Ian change document?
DanC: since we're not taking the "almost ready to publish" approach, I'm inclined to have you incorporate changes as you see fit.
ChrisW: when you make substantive changes, notify us by email. (public-html)
DanC: what exactly is the current version, for reference?
<Hixie> whatwg.org/html5 and whatwg.org/wf2
<Hixie> whatever is current when it happens
<Hixie> revision 1000
<DanC> what's the current version? or md5sum?
need version number pasted into IRC
<DanC> really? v1000?
<Lachy> 785 is the latest
<Hixie> (no, we're at 785)
<Hixie> (but the revision being proposed is whatever is latest when we take it)
DanC: proposal is to use Web Applications 1.0 as base
<Hixie> today's version is 785
<Hixie> but it'll probably be 788 by tonight
<Hixie> and 800 by next week
DanC: I'm partial to the ammendment to have Dave Hyatt as well as Ian as editor.
<josef> anne5: thanks, is there such a tracker for wf2 too?
<Hixie> i mean, the spec has revved twice just in this phone call!
<hsivonen> it doesn't make sense to throw away the work WHATWG will do by the time this WG reaches the decision
<anne5> josef, wf2 probably won't get changes anymore
<anne5> josef, the idea is to fold it in
<DanC> http://dev.w3.org/cvsweb/html5/ is a useful sync mechanism
DanC: I'm inclined to put the question today and give WG a group a week to answer
DanC: item 4 on agenda - have
proposal from 9 april 2007 to use HTML5 and WF2 as basis for
... if we adopt proposal, comments will be expected w.r.t. this text; the editors will be expected to respond to comments; if issue particularly sticky, alert chairs and will be discussed, perhaps added to group issues list, etc.
<Hixie> the current whatwg spec is definitely not in stone
<Hixie> i have 1000s of outstanding comments to deal with still
DanC: the proposal does not
establish a technical status quo such that new information is
needed before anything is changed; nothing set in stone
... logistics... sufficient to send email to ask questions or use WBS forms?
<Lachy> I don't want more +1s on the list, use a WBS form
<mjs> I would also suggest a WBS form
<mjs> for something of this scale it's good to have things on the record
DanC: preference seems to be fore WBS. ChrisW, can I get you to look over a survey in detail today or tomorrow?
<MattRaymond> What is WBS?
DanC: OK; we'll use a WBS form;
one vote per member; if votes are all yes and abstaining then
carries; if there are objections, then chairs will decide
whether the question carries
... one vote per member; invited experts also get to vote
<JacksonW> gotta go... thanks folks
DanC: we're not not looking for majority or popular vote; our goal is but consensus; if you object you're expected to have a substatial reason why.
<Hixie> i gotta go, i have another meeting
DougS: if issue comes up were wide amount of disagreement - who decides: chairs? editors? to what degree are editors responsible to WG?
DanC: consensus means many yes votes and no objection, but the chairs can decide that a question carries despite lack of consensus.
<DanC> ACTION: DanC to put the HTML spec baseline discussion by WBS in the next day or so [recorded in http://www.w3.org/2007/04/26-html-wg-minutes.html#action04]
<MattRaymond> Does consensus require absolute zero against?
DanC: will give everyone a full week to respond
<chaals> [please generally give a week for WBS questions]
consensus = zero against
will we meet with some regularity?
DanC: We're authorized by charter
to meet up to 1 time per week
... I would like to have 2 scheduled times: one good for North America and Europe one good for Asia, and choose at chair's discretion
<hsivonen> I suggest preferring mailing list over telecons
ChrisW: don't want a weekly telecon; volume of email already swamping; telecon not going to help that dramatically; do want to meet regularly - once every month; actually twice every month with overlapping times
nine hour difference between Boston time and Australian time
DanC: ChrisW - you probably will be chairing the asian meeting; DanC is happy to chair at this time 1pm EDST once a month
<scribe> ACTION: ChrisW to try to find a Seattle/OZ/Asia time [recorded in http://www.w3.org/2007/04/26-html-wg-minutes.html#action05]