See also: IRC log
will be about 5 minutes late to call in, apologies
<scribe> Scribe: Gregory_Rosmaita
<scribe> ScribeNick: oedipus
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
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]
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
RM: any pressing issues?
ADJOURNED
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]