XHTML2 Working Group Teleconference -- 19 Nov 2008

<trackbot> Date: 19 November 2008

<scribe> Scribe: Gregory_Rosmaita

<scribe> ScribeNick: oedipus

RM: regrets from Steven who is sick

Agenda Review, News and New Items

<markbirbeck> on my way...just be a minute...

<alessio> hi all :)

http://www.w3.org/MarkUp/tracker/agenda

SM: disposition of comments for Access and Role are done and are up - just updated today

RM: all necessary to move forward

SM: for Access and Role, yes; CURIEs already in process

State of Documents/Deliverables

<alessio> Tina, I'm just writing a post for italian community about your XHTML article on "The Developer’s Archive"

RM: SP sent transition requests; nothing scheduled yet as for publication; waiting for commm team

<Tina> alessio: excellent. Thank you.

RM: Role and Access Modules in same state; WG voted to forward; drafts ready and disposition of comments are also ready

<scribe> ACTION: Steven - request CR Transition for Role Module [recorded in http://www.w3.org/2008/11/19-xhtml-minutes.html#action01]

<trackbot> Created ACTION-30 - - request CR Transition for Role Module [on Steven Pemberton - due 2008-11-26].

<scribe> ACTION: Steven - request CR transition for Access Module [recorded in http://www.w3.org/2008/11/19-xhtml-minutes.html#action02]

<trackbot> Created ACTION-31 - - request CR transition for Access Module [on Steven Pemberton - due 2008-11-26].

XML Events 2 progress towards last call

RM: WG voted to send XML Events 2 to LC
... any comments on Events document?
... do we need to resolve outstanding actions?
... Action 1 is first: http://www.w3.org/MarkUp/tracker/actions/1

<Roland> http://www.w3.org/MarkUp/tracker/actions/1

<ShaneM> ACTION: Shane to update XML Events 2 draft so it has a diff mark to previous public working draft AND to the previous recommendation [recorded in http://www.w3.org/2008/11/19-xhtml-minutes.html#action03]

<trackbot> Created ACTION-32 - Update XML Events 2 draft so it has a diff mark to previous public working draft AND to the previous recommendation [on Shane McCarron - due 2008-11-26].

RM: only way can write need to be done before any other event fired - does it make significant difference for last call?

SM: be ok to put in comment perhaps -- not an open issue - not from reviewer -- WG not sure if on right track

RM: could put in as comment that welcome feedback on that particular statement

AC: agree

RM: reviewing actions on me: action 1 "- write to DOM3 guys on when registration will occur and when events can be fired; coordinate deeper discussion"
... can we put comment into spec saying welcome feedback on timing or do we need something more definitive

MB: something we raised ourselves;

RM: action on me was to open dialog on subject with DOM3 people
... another topic - DOM3 going to LC by end of first quarter of next year; should re-examine to ensure XML Events work in DOM2 and DOM3

SM: isn't that the issue: we need qnames, and if so, we need DOM3 Events?

MB: could do mapping at implementation layer; DOM2 doesn't have qnames, but layer on top could

RM: do we need qnames - if have event with qnames, can use, if not, then don't use

SM: do you believe that DOM2 events permit the definition of arbitrary events

MB: those with colon?

SM: in general - defined collection of event tokens that can't be extended

RM: did that with XML Events 1

SM: can you put colon in name - i say no because is a token

MB: one way to go is to follow RM's lead - depends on architecture which to use; if use DOM2, qnames not supported (should be explicitly stated)

SM: needed to write portable documents

MB: could map it

SM: how would approach?

MB: XML Events 2 layer is goig to have to have sub-code written to have calls made to DOM2 or DOM3 -- something underneath, core code, will have to do registration of events
... given system self-contained xyz:event mapped to xyz_event no one would be any the wiser

SM: ok

MB: self-contained system; weak point - XForms has xforms-submit but can't have xf:submit then

SM: MB's approach clean - have to put in normative requirement on DOM2 events, and no normative req on DOM3 events; problem of timing; can't rely on DOM3

MB: we don't have to do mapping; implementation does it

SM: "must behave as if..." is all that is needed
... implementations based on DOM2 events MUST behave as if specified by qnames; the exact method is implementation-defined

MB: ok

SM: where in spec to put comment?
... think needs to be in definition of event attribute

RM: agree - in Events part of spec

<alessio> +1

SM: listener elements and DOM3 Event Mutation
... does DOM3 have all interfaces we are exposing? all subjects in handler module and bubbling stuff - default target, etc. -- 4 potential phases in DOM2 - have to clarify situation vis a vis DOM3
... phases is ok -- we define what each term means in the spec

MB: one level up events are ok

SM: others of interests: DispatchEvents, etc. - those are our definitions; style propagation and prevent default already in DOM2

MB: on DOM3 question, are they still considering using qnames?

RM: yes, although faction oppose

SM: interestingly, the last draft of DOM3 Events, from 2007, doesn't contain term qname
... does have NamespaceURI as attribute
... don't use qualified name either

<ShaneM> http://www.w3.org/TR/DOM-Level-3-Events/events.html#Events-Event

SM: events interface in DOM3 defines addEventListener and addEventListenerNS - that is interesting and shows way towards mapping; if interface like this, no mapping needed, if not, know what to do

MB: by spliting namespace out into seperate property and not using qnames, trying to ensure baackwards compatibility -- use local name, may not be namespace present
... should we be doing the same

SM: not needed for our users

MB: assuming that using qnames is more convenient than using 2 attributes, one with namespace and one with type

SM: namespace prefix going may be used hundreds of times -- burden on author
... foo:bar implies a namespace

MB: does imply that alogrithm foo:bar becoming foo_bar is wrong; in DOM2 becomes just bar
... initEvent method receives bar; if eventsNS receive bar plus the foo
... note needs to state: be careful, if use DOM2 foo will be ignorned and foo:bar and foo_bar will map to same event

SM: approach might work, but could also say - if ontop of DOM2, should treat foo:bar and bar identically

MB: 2 methods: one with namespace property and one without

SM: latest editor's draft?
... define spec on our side that allows our constituents to write applications; no idea what underlying implementation is

RM: DOMHasFeature will tell you that

SM: XML Events 2 not scripting, but declarative through use of handlers
... can't serve diff documents depending upon underlying document type -- at least, i wouldn't want to

MB: what is use of qnames -- in local files, defining my events, don't need qnames; become useful when people write specs xf:done

SM: good point;

MB: author has control of document

SM: sometimes

MB: use qualified names with multiple markup

SM: if constituency is basic author, not going to use qnames for own events

RM: this is language-designer concern only?

SM: do we want to tell users "don't use qnames for your own defined events"
... "If you use qualified names, in some implementations, they may collide"

MB: not convinced there is a perfect solution to this; what is it that DOM3 event designers seeing when took this approach; AJAX library fires event when initialized and make dojo:done - can i register that?
... perhaps dojo:done should be different that yahoo:done

RM: how do we move forward? next steps?

MB: need to ascertain from DOM what were thinking - can attach event with one technique and can fire event with another
... what is effect we are attempting to achieve
... at script level could register event using AddEventListenerNS
... also generic AddEventListener - if author writes DOM2 code to register event, another author may write a DOM3 firing of event using different methods; may be why said xyz_bar same as foo:bar
... doesn't bring us any closer to next step, though...

RM: perhaps have to step back and ask question: "Do we think we should accomodate DOM2 events or move forward and use DOM3 events"
... should we tie ourselves to DOM3?

MB: i would no, interim step here -- XForms uses DOM2 events, ended up with if and for which migrated to XML Events
... reason for qnames addition, was to support future when DOM3 finalized; follow evolution of DOM2 events into DOM3 -- if can't figure out solution, should leave out qnames for now -- would not want to be tied to DOM3 Events because may not be done for 4 years

RM: other thoughts?

SM: can go back to DOM2 Events; could potentially provide guidance - intent to support qnames via DOM3 Events in future, and devs might want to keep that in mind
... unfortunate Steven not here; would like to hear his input before make decision

<alessio> true

RM: thinking about the issues won't harm us, only benefit us
... soften question about DOM3 - should support DOM3, but requiring DOM3 different; capable of supporting DOM3 in compatability mode from earlier versions
... add new features from capability point of view; can support some DOM3 features when deployed

SM: like that story-line -- trying to get XML Events 2 deployed now

RM: entire WG should take time to review this -- anyone want to write up proposal and send to mailing list to capture the position we reached today, then revisit at call in 2 week's time

[complete silence]

RM: anyone want to try and summarize where we just go to?

SM: can do in an email

RM: thanks, shane

Upcoming Calls

RM: next week is thanksgiving - will there be enough attendees?

SM: available

TH: available

AC: yes

MB: no

GJR: yes

<alessio> :)

RM: i will - SP has actions to clear before he takes off in december - will ask him to clear as much as can before december
... leave decision on DOM2 and DOM3 to meeting 2 weeks from today - Mark will you be here?

MB: no, unavailable

<ShaneM> ACTION: Shane to write a quick summary of the position w.r.t. DOM2 vs. DOM3 in XML Events 2 [recorded in http://www.w3.org/2008/11/19-xhtml-minutes.html#action04]

<trackbot> Created ACTION-33 - Write a quick summary of the position w.r.t. DOM2 vs. DOM3 in XML Events 2 [on Shane McCarron - due 2008-11-26].

RM: can you make sure you get your views and opinions onto emailing list so can make decision

MB: yes

Roadmap for XHTML2

RM: gregory been pushing; believe agreed should get new draft out; what were we waiting for

SM: editing cycles

RM: like to get to LC by end of first quarter of next year?

SM: a year ago was next public draft would be LC --

RM: think at june f2f decided to publish public draft

SM: need to get to it

RM: when can we get a draft out? by moritorium - next month

SM: moritorium?

RM: normally one during holiday period
... can we get another draft by 2 weeks

SM: everything else done, so have more time to work on XHTML2 and XML Events

RM: will try and draft a roadmap for XHTML2 that we can then discuss as to its reasonableness at next week's call

<scribe> ACTION: Roland - draft roadmap for XHTML2 to discuss reasonableness at next call [recorded in http://www.w3.org/2008/11/19-xhtml-minutes.html#action05]

<trackbot> Created ACTION-34 - - draft roadmap for XHTML2 to discuss reasonableness at next call [on Roland Merrick - due 2008-11-26].

XHTML Mime

SM: addressed all of opera's issues; ready to go
... have a free weekend, so expect to get work done

Lingering Items

RM: PERs for 1.1 (dependent upon having new note on mime); continue with modularization

SM: all done -- PERs ready - just need date; depends on whether can get CR stuff in and if can do anything when steven gone for a month

RM: i will discuss PERs with steven

SM: happy to have meeting with RM and SP to come up with work plan for December

Action Item Review

SM: action 4 - replying to forms content on access module

<ShaneM> http://www.w3.org/MarkUp/tracker/actions/4

SM: replied formally to TAG on 18 October 2008; not acknowledged; think can close with a "no response"

RM: MarkB, could you bring this up in XForms call?

<scribe> ACTION: Mark - ask XForms about Access Module concerns [recorded in http://www.w3.org/2008/11/19-xhtml-minutes.html#action06]

<trackbot> Created ACTION-35 - - ask XForms about Access Module concerns [on Mark Birbeck - due 2008-11-26].

<ShaneM> http://lists.w3.org/Archives/Public/www-html/2008Oct/0011.html

SM: may not have been responded because didn't submit LC to right list - sent to www-html not to our either of public lists
... Mark, please ask them to look at the post referenced above
... with respect to action 4 will put in link to related email, but think should close

RM: agree - action was to reply

TH: issue on roadmap - 4 different types of list comment

RM: can we clear in 5 minutes

TH: initial reaction is to suggest that we say "thank you for your opinion, but we don't agree with you" don't think should go from specific set of elements to generic set of elements

RM: last week we said we had 4; feeling was 3 is good, but is NL necessary

TH: need more, not less
... NL is a generic list of links with specific semantics which UL doesn't have

RM: could use any of other 3 list types with role="navigation"

SM: NL implies certain behavior and certain semantics about content; NL implies orderedness that UL does not, and OL is inappropriate construct for navigation

GJR: plus 1 on keeping NL

<_alessio> +1 too

MB: don't like NL -- my problem is why stop at NL, why not video list -- ability to turn anything into hyperlink in XHTML2 hard to figure out the semantics;
... understand why added NL, but think that role made superfluous

TH: semantics, traditionally, has been placed in element type name; UL, OL, DL, and generic list with role="navigation"

MB: what is generic list?

SM: not thinking of adding generic list

MB: either use semantics to clarify lists (people tend to use @class to do that)

<Roland_> http://www.w3.org/html/wg/html5/#the-nav-element

RM: HTML5 dealt with this with nav element

TH: like to see "inline list", but need to look at our philosophy; strictly speaking could end up with 1 element and 3 attributes; big step away from precedent

MB: guiding prinicple of XHTML2 is "less is more" -- do talk about not having just DIVs and SPANs, but ensuring hooks in language so that people can add own semantics - that's what @role introduced;

TH: can extend as needed in XHTML M12n framework - extend XHTML via namespaces

<_alessio> I'm not against nl but I see some warnings for nested lists

MB: you are saying that preferred extension method should be elements; have to write special module for extension

<_alessio> for example what about an unordered list with his role="navigation" inside an nl?

MB: other method is use attributes and allow identifier in there - with role and RDFa used RDF identifiers or URIs to merge with semantic web

GJR: there are XML derived modules for shipping addresses and such

<ShaneM> sorry - I have to run

RM: need to examine HTML5 additions

<_alessio> agree

<markbirbeck> bye...have to go to XForms call

RM: good to document philosophy behind XHTML2

GJR: good place to start is verbiage in spec

TH: can't avoid what authors doing

RM: need to develop policy
... should spend time thinking about a policy to apply would be useful
... prefer do on overall approach on how we deal with issues instead of one-off solutions and ad hoc solutions

<_alessio> bye! :)

s/good place to start is with the extant Introduction/good place to start is with the extant Introduction (http:\/\/www.w3.org\/MarkUp\/2007\/ED-xhtml2-20071024\/introduction.html#s_intro_whatisxhtml2)

- DRAFT -

XHTML2 Working Group Teleconference

19 Nov 2008

Attendees

Contents