W3C

- DRAFT -

XHTML2 WG Weekly Teleconference

16 Jul 2008

Agenda

See also: IRC log

Previous

Attendees

Present
Roland, markbirbeck, ShaneM, Tina, Alessio, Gregory_Rosmaita
Regrets
Steven
Chair
Roland
Scribe
Gregory_Rosmaita

Contents


 

will be about 5 minutes late to call in, apologies

<scribe> Scribe: Gregory_Rosmaita

<scribe> ScribeNick: oedipus

Agenda Review

RM: Shane and Tina supposed to collaborate on something

SM: we are working on it

RM: review of XSD 1.1 - MarkB best person to do this, willing to volunteer?

MB: yes - due date?

RM: 12 september 2008

<scribe> ACTION: MarkB - review XSD 1.1 - Due: 2008-09-12 [recorded in http://www.w3.org/2008/07/16-xhtml-minutes.html#action01]

RM: CURIE Syntax transition

SM: if haven't heard back in 2 weeks, should poke them again

RM: will investigate and try to expedite
... XHTML <=> HTML5 positioning - nothing new
... Role Attribute Module - Resolution to request CR Transition made 2008-07-09
... some outstanding tasks
... action on GJR why "similar" instead of stating derived from role

GJR: ARIA's Relationship to Role Module Inquiry: http://lists.w3.org/Archives/Public/public-xhtml2/2008Jul/0012.html

on agenda for today's PF call

RM: XHTML Basic 1.1 transition to PR: status - waiting for votes; email about inconsistencies in text - should review; voting closed yesterday
... re-organization of groups in domains
... M12N transition: status same as XHTML Basic 1.1

Access Module Comments

RM: feedback from SVG WG: http://lists.w3.org/Archives/Public/www-html-editor/2008JulSep/0002.html

<alessio> http://lists.w3.org/Archives/Public/www-html-editor/2008JulSep/0002.html

RM: reactions?

SM: useful to go through this item by item

RM: agree

SM: they say they are concerned about dependency on core attribute selection
... not sure how to respond

RM: many of our modules have bits which could and should be reused

Alessio: yes

SM: specific issue: access module does not have a dependency on core attributes collection, but ID attributes collection
... wouldn't be adverse to changing text to highlight ID attribute dependency
... don't think really a dependency on any of them

SVG comment: This is a problem for SVG, since the Core Attribute Collection [3] lists:

xml: space ("default"* | "preserve"), class (NMTOKENS), id (ID), title

(CDATA)

SM: doesn't need comment - in minimal collection
... integrating with XHTML2 - but nothing from attributes that are required for functinoality

RM: clarify in attributes section of spec?

SM: think req on core attribute selection hold over from HTML
... dependency is targetid needs to know where to go

RM: define that - goes to something with an id value

SM: exactly

RM: @id values must be unique - xml:id or id wouldn't matter from targetid POV

SM: true

RM: agreement to remove comment from core attribute collection from conformance

<alessio> +1

proposed RESOLUTION: remove comment on core attribute collection from conformance

SM: "Title and Description for <access> Element
... want us to allow child elements, but not how we do it
... requesting TITLE and DESC to model, but looking for 4 state XForms model; extension mechanism available for access in our namespace

RM: M12n will allow SVG to add child elements?

SM: yes
... may be that implementations don't make that easy

<scribe> ACTION: Shane - investigate implementation to ascertain how difficult will be to add child elements in M12n [recorded in http://www.w3.org/2008/07/16-xhtml-minutes.html#action02]

RESOLUTION: remove comment on core attribute collection from conformance in accordance with SVG formal comment

RM: targetrole and targetid values comment

SVG comment: "It doesn't seem intuitive that the targetrole and targetid lists are

unordered, but rely solely on document order. For SVG in particular,

document order is of a different nature than in XHTML; it determines the

stacking order, not the sequential order. We do understand that both

unordered and ordered lists have use cases; therefore, we suggest that

you introduce a way for the author to control the 'tabbing' order.

"

SM: don't mind addition -- allows documentation of tab order

SVG request: "attribute 'order' = "document* | list"

SM: not the target accessibility community wants - not sure would affect accessibility pro or con
... will adding capability change its accessibility aspects?

<scribe> ACTION: Gregory - bring up SVG's proposal for attribute 'order' to ascertain if affects accessibility qua accessibility [recorded in http://www.w3.org/2008/07/16-xhtml-minutes.html#action03]

RM: tabindex in general...

SM: don't use tabindexing -

Alessio: maybe should emphasize role - not just affects order for UI, but semantic order of document; need way to navigate inside document, so think is right to guide user, but can we use only to define tabbing order

SM: agree with Alessio; don't think in terms of tab order, but defining navigation sequeence associated with access element; introducing role will complicate things - can have many elements with sam role

Alessio: understand Shane's concerns - need a way to order navigation inside elements
... think that there are many people who decide the tabindex order besides user; tabindex 200 to 1000 defined may be conflicts; complicated issue

GJR: agree will try and get more clarification through PF

RM: need more work/thought on this

MB: attribute order equals - AlGilman asked for ability to set sequence through document; decided should be left for later; targetid states these are the ids affected by this key; if mix up with role, may pose problem; sequence of roles regardless of keys - more abstract layer to work on in future
... need more thought on this; now talking about sequence of list in relation to role and id at some level; may recycle discussion at top-level

SM: reaction to paragraph 2 - can remove that and say implementation defined by host language / up to host language to define order

MB: yeah

GJR: hmmm.. intrigued

SM: potentially in conflict with other developments with XHTML2

RM: stepping back to "up to host langauge" position ok, but what happens when SVG, MathML and others don't gel because all taken different approaches
... normatively don't say, but could ask for guidance on how to implement in host language; if requirements to do something different, do what is best for your domain and ML based on purpose and expertise

MB: UAs mixing XHTML and SVG - can have 2 levels of navigation - once get into SVG have different controls until get out of SVG and back into XHTML; SVG buttons and checkboxes not clear what is next

GJR: Elemant Traversal draft applicable?

RM: suggest back off as Shane suggested; not going to define order - up to host language incorporating it - but if have no idea what to do, start with document order unless reason to do otherwise

http://www.w3.org/TR/ElementTraversal/

Element Traversal abstract: "This specification defines the ElementTraversal interface, which allows script navigation of the elements of a DOM tree, excluding all other nodes in the DOM, such as text nodes. It also provides an attribute to expose the number of child elements of an element. It is intended to provide a more convenient alternative to existing DOM navigation interfaces, with a low implementation footprint."

proposed ACTION: ShaneM - update wording on navigation order in response to SVG WG comments

<scribe> ACTION: ShaneM - update wording on navigation order in response to SVG WG comments [recorded in http://www.w3.org/2008/07/16-xhtml-minutes.html#action04]

SM: next comment: multiple keys for same target element
... no problem with comment

RM: seems reasonable

GJR: plus 1

<alessio> yes

RESOLUTION: accept SVG comment on Multiple Keys for Same Target Element

SM: external document use comment: should ignoring multiple frame comment, for now

<alessio> interesting issue

SVG comment on external document use: "We believe there is a use case for referencing elements in another document, such as in a scenario where multiple frames are loaded. Please consider if an IDREF is the appropriate value for the targetid attribute, given this scenario."

RM: assumption that dealing with 1 document; to address multiple documents a whole 'nother kettle of fish

SM: in case of XML Events, have CURIE syntax; for this comment, don't think makes sense to change targetid attribute

MB: could be IDREFS or URIs

SM: remember plural; get to one, and then lost context -- what to do?
... can see having targeturi as another alternative - not sure what it buys, but if satisfies comment...

MB: out of scope - similar things raised about Events crossing boundaries; need more coherent picture as to how to make that work to make this work

RM: compact document type - when go into component, should be point of entry, and access within would have to be defined by those components
... documents and widgets embedded in page, get black box from outside

GJR: points out ARIA approach

MB: those scenarios easier - if part of parent DOM, but don't know internal thing, can identify it because in same DOM (knows y is a child) - don't know how to navigate; document with IFRAMEs hop from one to another

GJR: ARIA trying to address navigational "traps" posed by widgets and embedded objects and should provide ability to list and traverse all objects of type x

MB: targetid about IDREFs and anything beyond that is beyond scope for now

SM: objections?

Alessio: agree

TH: agree

GJR: agree

SM: can do what they want with 2 elements - access element that targets something in document and embedded document - but that is for XML Events
... will make edits agreed to

<scribe> ACTION: Shane - respond to SVG formal review of Access Module [recorded in http://www.w3.org/2008/07/16-xhtml-minutes.html#action05]

XHTML2 new draft

SM: don't know when will be finished; keep getting sidetracked by other w3c things;

TH: have a number of comments for you, Shane

SM: plan is to work on XHTML2 this weekend - real issues want to discuss

RM: go ahead

SM: during Face2Face, direction i got was remove from XHTML2 section that defines things that are in other specs so that not defined twice, which makes sense; @meta, XForms, XML Events 2, etc. -- removed, but then realized lost content model
... purpose of section to proviide content model; tried to shoehorn-into draft under mime types, doesn't really fit; doesn't explain how to write XHTML2
... assume goal is person reading spec will understand what elements and attributes are available, and where they are permitted

[general agreement]

SM: XForms defines content model in respect to XHTML, so we have to do it but how? put back in - here are elements and attributes and how they work

RM: show content model, not what each item means

MB: tricky with XForms

SM: started down that road, but concern is that someone will say, "i have to read 5 other specs to find out what XHTML2 is" -- need to agree if that is ok

RM: opportunity for someone to make money writing a book on that

SM: put chapters back in, but remove content, so only table at top that defines elements and attributes with one or 2 sentences on how integrate into content model

TH: and reference other docs?

SM: explicitly link out to the right part of the referenced specs for each element
... have to figure out elegant way to do that

RM: present information that is useful for authors and not just understanaable by specification wonks
... can provide a deliverable - composite content model for authors

SM: way back when, debate was XHTML2 or M12n 2 - group decided XHTML2, but based on modules that can be assembled into other things; there are 2 things: the language and the toolkit - have to cover both

RM: don't want authorial redundancy with other MLs

Wrapping Up

RM: any pressing issues?

ADJOURNED

Summary of Action Items

[NEW] ACTION: Gregory - bring up SVG's proposal for attribute 'order' to ascertain if affects accessibility qua accessibility [recorded in http://www.w3.org/2008/07/16-xhtml-minutes.html#action03]
[NEW] ACTION: MarkB - review XSD 1.1 - Due: 2008-09-12 [recorded in http://www.w3.org/2008/07/16-xhtml-minutes.html#action01]
[NEW] ACTION: Shane - investigate implementation to ascertain how difficult will be to add child elements in M12n [recorded in http://www.w3.org/2008/07/16-xhtml-minutes.html#action02]
[NEW] ACTION: Shane - respond to SVG formal review of Access Module [recorded in http://www.w3.org/2008/07/16-xhtml-minutes.html#action05]
[NEW] ACTION: ShaneM - update wording on navigation order in response to SVG WG comments [recorded in http://www.w3.org/2008/07/16-xhtml-minutes.html#action04]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.133 (CVS log)
$Date: 2008/08/20 15:10:30 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.133  of Date: 2008/01/18 18:48:51  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/SM: concerned/SM: they say they are concerned/
Found Scribe: Gregory_Rosmaita
Found ScribeNick: oedipus
Default Present: Roland, markbirbeck, ShaneM, Tina, Alessio, Gregory_Rosmaita
Present: Roland markbirbeck ShaneM Tina Alessio Gregory_Rosmaita
Regrets: Steven
Agenda: http://lists.w3.org/Archives/Public/public-xhtml2/2008Jul/0014.html
Got date from IRC log name: 16 Jul 2008
Guessing minutes URL: http://www.w3.org/2008/07/16-xhtml-minutes.html
People with action items: - attribute bring for gregory implementation investigate markb order proposal respond s shane shanem svg up

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.
[End of scribe.perl diagnostic output]