Chatlog 2009-03-26

Jump to: navigation, search

See original RRSAgent log and preview nicely formatted version.

Please justify/explain all edits to this page, in your "edit summary" text.

12:52:38 <RRSAgent> RRSAgent has joined #xhtml
12:52:38 <RRSAgent> logging to
12:52:45 <Zakim> Zakim has joined #xhtml
12:52:52 <Steven> rrsagent, make log public
12:53:06 <Steven> Meeting: XHTML2 WG Virtual FtF
12:53:13 <Steven> Chair: Roland
12:54:47 <Steven> zakim, room for 8 at 13:00z for 240 mins?
12:54:49 <Zakim> ok, Steven; conference Team_(xhtml)13:00Z scheduled with code 26634 (CONF4) at 13:00z for 240 minutes until 1700Z; however, please note that capacity is now overbooked
12:55:00 <Roland> Roland has joined #xhtml
12:55:39 <oedipus> agenda:
12:55:51 <oedipus> scribe: Gregory_Rosmaita
12:55:57 <oedipus> ScribeNick: oedipus
12:56:03 <oedipus> rrsagent, make minutes
12:56:03 <RRSAgent> I have made the request to generate oedipus
12:56:10 <Steven> code is CONF4
12:56:24 <Steven> 26634
12:56:36 <Steven> Steven has changed the topic to: Code is CONF4 (26634)
12:56:59 <Zakim> Team_(xhtml)13:00Z has now started
12:57:01 <Zakim> +Roland_Merrick
12:57:17 <Roland> Zakim, Roland_Merrick is Roland
12:57:17 <Zakim> +Roland; got it
12:57:33 <Zakim> +Gregory_Rosmaita
12:57:35 <Zakim> -Gregory_Rosmaita
12:57:35 <Zakim> +Gregory_Rosmaita
12:58:17 <mgylling> mgylling has joined #xhtml
12:59:40 <Zakim> + +
12:59:58 <oedipus> previous:
13:00:10 <oedipus> zakim, aaaa is Markus
13:00:10 <Zakim> +Markus; got it
13:00:16 <oedipus> rrsagent, make minutes
13:00:16 <RRSAgent> I have made the request to generate oedipus
13:00:30 <Steven> zakim, dial steven-617
13:00:30 <Zakim> ok, Steven; the call is being made
13:00:32 <Zakim> +Steven
13:01:40 <oedipus> TOPIC: Agenda Review
13:01:56 <Roland>
13:02:40 <oedipus> 4 XHTML2 items: the P content model, Navigation (nl in or out?), Semantics and Elements versus Attributes, how to incorportate ITS
13:02:55 <oedipus> RM: start with news from the A.C. meeting once reach critical mass
13:03:08 <alessio> alessio has joined #xhtml
13:03:16 <oedipus> SP: would very much like to report, but want shane and mark to be here when i do
13:03:57 <oedipus> RM: brief update on PER
13:04:20 <oedipus> zakim, who is here?
13:04:20 <Zakim> On the phone I see Roland, Gregory_Rosmaita, Markus, Steven
13:04:21 <Zakim> On IRC I see alessio, mgylling, Roland, Zakim, RRSAgent, Steven, oedipus, trackbot
13:05:33 <Zakim> +??P17
13:05:41 <oedipus> MG: Shane said he'd be late yesterday
13:05:48 <oedipus> zakim, ??P17 is Alessio
13:05:48 <Zakim> +Alessio; got it
13:05:49 <alessio> zakim, ??P17 is Alessio
13:05:49 <Zakim> I already had ??P17 as Alessio, alessio
13:06:17 <oedipus> rrsagent, make minutes
13:06:17 <RRSAgent> I have made the request to generate oedipus
13:06:53 <oedipus> scribe's note: [steven ping outliers]
13:07:43 <oedipus> minutes from last regularly scheduled meeting:
13:08:06 <oedipus> rrsagent, make minutes
13:08:06 <RRSAgent> I have made the request to generate oedipus
13:08:46 <oedipus> RM: brief update with PER?
13:08:50 <oedipus> TOPIC: PER Update
13:09:34 <oedipus> SP: didn't make friday deadline due to AC meetings; have to get fiinished; still moritorium this week on publishing due to AC meeting, should be published next week, if all goes according to plan
13:09:45 <oedipus> RM: just matter of questoinnaires?
13:10:21 <oedipus> SP: PER has to be voted upon; extra administrivia - creating detailed questionnaires with pointers (creating now - have to go out simultaneously with PER anouncement)
13:10:26 <oedipus> RM: that's all we need do?
13:10:28 <oedipus> SP: yes
13:10:37 <oedipus> RM: any other administrivia?
13:10:57 <oedipus> scribe's note: deafining silence
13:12:27 <oedipus> GJR: in response to feedback and discussion at last virtual f2f i have updated the "for" attribute proposal
13:12:28 <oedipus>
13:12:37 <ShaneM> ShaneM has joined #xhtml
13:13:11 <oedipus> GJR: changes: proposed for Text Attributes collection, not Core collection
13:14:10 <oedipus> 1. That the for/id mechanism, which is already broadly supported in user agents and assistive technologies, be repurposed and extended in XHTML2 to provide explicit bindings between labelling text and the object or objects that text labels;
13:14:10 <oedipus> 2. That the for/id mechanism serve as a means of re-using values for: ABBR, D (the single letter "dialogue" element), DFN; 
13:14:10 <oedipus> 3. That the for/id mechanism serve as a means of binding a quotation, contained in the Q element, and a corresponding CITE declaration which identifies the source of the quote;
13:14:11 <oedipus> 4. That the for/id mechanism serve as a means of marking text which has been inserted, contained in an INS, and that which it is intended to replace, contained in a DEL tag, as illustrated below; 
13:14:13 <Zakim> +McCarron
13:14:21 <ShaneM> zakim, McCarron is ShaneM
13:14:21 <Zakim> +ShaneM; got it
13:14:37 <oedipus> rrsagent, make minutes
13:14:37 <RRSAgent> I have made the request to generate oedipus
13:15:18 <oedipus> TOPIC: News & Notes - AC Meeting Report
13:15:32 <oedipus> SP: much of AC meeting, but not all, in sphere of HTML5 and XHTML2
13:16:40 <oedipus> SP: started monday morning with panel - XHTML2 side represented by myself and ben adida (made cross-continental day trip); neutral people: Larry McMaster from Adobe; and HTML5 people represented mainly by David Baron
13:17:19 <oedipus> SP: nothing much to report about it; Hegeret was chair; put questions to panel; people in audience put questions as well -- no demos, just Q&A
13:17:24 <oedipus> RM: link to AC minutes?
13:17:58 <oedipus>
13:18:07 <Steven>
13:18:09 <oedipus>
13:18:13 <oedipus>
13:19:21 <oedipus> SP: Chaals McN web standards oriented; Larry MM neutral; Sam Ruby co-chair of HTML WG; David Baron works for Mozilla, very much HTML5er; Henry Thompson, Ben Adida and myself (Steven Pemberton)
13:19:57 <oedipus> SP: at least 2 negative comments from audience: Daniel Glazman (not there physically but on IRC) - very anti-XHTML2
13:21:01 <oedipus> SP: Arun (represents mozilla) - need to ask why against XHTML2 in W3C?  don't think mozilla is anti-XHTML2, but hard to separate personal opinions from corporate agendas; aim is to close down XHTML2
13:21:21 <oedipus> SP: good feedback after panel; lots of red herrings being spread in discussion; tried to expose falicies
13:21:40 <oedipus> SP: after that meeting had breakout groups - about 20 in XHTML2 breakout group
13:22:13 <oedipus> SP: not minuted in IRC, hand-made minutes - trying to find if up in w3c space yet
13:23:02 <oedipus> SP: 2 breakout groups: 1st day: discuss issues (extended panel) - on second day, discussion on what to do with situation
13:23:51 <oedipus> SP: second breakout more interesting; discussion unencumbered by knowledge of what XHTML2 is all about; Raman and Charlie Wiecha of IBM knes about XHTML2, but rest of participants very shallow knowledge
13:24:22 <Tina> Tina has joined #xhtml
13:24:25 <oedipus> SP: asked who is using 2 technologies; one person said, "since HTML5 seeks to make all pages conformant to HTML5, HTML5 is what people use
13:24:44 <oedipus> SP: explained modularization and the packaging of modules to create XHTML2
13:25:10 <oedipus> SP: because our charter has always been modularization, modules are deliverables; XHTML2 is a collectoin
13:25:39 <oedipus> SP: Arun surprised that there are big companies using XHTML and XForms
13:26:11 <oedipus> SP: meeting concluded with agreement that Sam Ruby and Steven Pemberton should work on merging HTML5 and XHTML2
13:26:52 <oedipus> SP: made it very clear in meeting that these aren't 2 slightly different markup languages, because underlying MVC architecture in XHTML2, that is laacking in HTMl5; would have to get HTML5 WG to accept that architecture so 2 can be merged
13:27:11 <oedipus> q+
13:28:24 <oedipus> SP: if choice between merging and not merging, think should keep separate unless agree to accept XForms and extensibility
13:29:57 <oedipus> SP: SamR and i can discuss to ascertain options
13:30:08 <oedipus> SP: in conclusion, think that we are now in stronger position
13:30:44 <oedipus> SP: 2 things can happen: HTML5 people reject collaboration or we do merge and HTML5 people required to take our approaches on board (m12n, MVC, etc.)
13:30:56 <oedipus> SP: either of those 2 choices much better than shutting down XHTML2
13:31:03 <oedipus> q?
13:31:22 <oedipus> SP: SamRuby is new co-chair of HTML5 - very positive interaction with him
13:31:52 <oedipus> SP: Sam Ruby wants to work together, but a lot of work to herd that enourmous herd of cats in HTML WG
13:32:33 <oedipus> SP: doubt that core HTML5 people will accept collaboration
13:32:41 <ShaneM> zakim, code?
13:32:41 <Zakim> the conference code is 26634 (tel:+1.617.761.6200 tel:+ tel:+44.117.370.6152), ShaneM
13:33:08 <oedipus> GJR: did sam mention the initative at mozilla to produce a rival spec to HTML5?
13:33:08 <oedipus>
13:33:08 <oedipus>
13:34:14 <Zakim> +??P15
13:34:28 <oedipus> RM: take more stable to have third version of HTML5
13:34:47 <oedipus> RM: pragmatic - how to achieve a deliverable
13:34:51 <Tina> Zakim, P15 is Tina
13:34:51 <Zakim> sorry, Tina, I do not recognize a party named 'P15'
13:34:55 <oedipus> SP: wasn't mentioned
13:35:04 <oedipus> zakim, +??P15 is Tina
13:35:04 <Zakim> sorry, oedipus, I do not recognize a party named '+??P15'
13:35:09 <oedipus> zakim, ??P15 is Tina
13:35:09 <Zakim> +Tina; got it
13:35:14 <Tina> Thank ye
13:35:16 <oedipus> rrsagent, make minutes
13:35:16 <RRSAgent> I have made the request to generate oedipus
13:35:19 <Tina> Zakim, mute me
13:35:19 <Zakim> Tina should now be muted
13:35:54 <oedipus> GJR: previous pointers: Rob Sayre of IBM is producing a new draft which is hixie's draft minus new inventions plus all the stuff that was removed
13:36:18 <oedipus> RM: will be taking features from HTML5 spec and adding them on; means of incrementally deploying HTML5
13:36:19 <Steven>
13:36:26 <oedipus> GJR: being deployed by fiat now
13:36:29 <Tina> Zakim, unmute me
13:36:29 <Zakim> Tina should no longer be muted
13:36:41 <oedipus> SM: more socially acceptable
13:37:11 <oedipus> RM: extensibility already being done by implementation by fiat of HTML5
13:37:31 <oedipus> SP: one discussion at AC meeting in first day's breakout group was lack of extensibility
13:37:48 <oedipus> SP: consensus of breakout group was extensibility needs to be supported
13:37:51 <oedipus> q+
13:38:01 <oedipus> SP: from POV of merging, extensibility essential
13:38:14 <oedipus> SP: long discussions about extensibility and what needs to be able to be done
13:38:30 <oedipus> SM: agreed upon definition of term "extensibility"?
13:39:23 <oedipus> SP: no definition or agreement on what would fall under rubric of extensibility; put forward strong view that people should be able to add own elements and attributes in standard way to foster new forms; cited XBL as example
13:39:34 <oedipus> SP: when i trace minutes for breakout groups will post link
13:39:38 <oedipus> ack oed
13:40:14 <oedipus> GJR: from WAI/PF's point of view extensibility and namespacing is essential, otherwise we will end up with ARIA 1.0 hard coded into HTML5, but we are already working on ARIA 2.0
13:41:05 <oedipus> GJR: WAI/PF needs to retain control over ARIA's vocabulary and definitions
13:41:22 <oedipus> SP: some people surprised that ARIA sprang from XHTML Role Module
13:41:54 <oedipus> SP: good to have BenA there on first day; would be wrong to give XML serialization to a group of people who fundamentally oppose and disllike XML/XHTML
13:41:59 <Zakim> -ShaneM
13:42:10 <oedipus> s/would be/Ben stated that it would be/
13:42:13 <oedipus> rrsagent, make minutes
13:42:14 <RRSAgent> I have made the request to generate oedipus
13:42:29 <oedipus> RM: return to this later - have a few comments
13:42:46 <oedipus> SP: worth watching discussion on AC forum; have to be on AC to contribute
13:43:03 <oedipus> GJR: one could always use www-archive for comments pointed at AC
13:43:25 <oedipus> SP: encouraged by meeting; interested in how the rest of the HTML WG responds to combining 2 groups
13:43:34 <oedipus> RM: should consider ramifications for XHTML
13:43:58 <oedipus> SP: LarryMM suggested i co-chair with Sam - not feasible
13:46:46 <Zakim> +ShaneM
13:46:56 <Steven> s/not feasible/not my idea of fun at the moment :-)/
13:46:57 <oedipus>  RM: first 2 topics also being worked on by HTML5
13:47:07 <oedipus> TOPIC: The P content model
13:47:13 <oedipus>
13:47:28 <Steven>
13:47:32 <oedipus> RM: HTML5 doing much of what we are doing with P - placing limitations on it
13:47:54 <Tina> Zakim, mute me
13:47:54 <Zakim> Tina should now be muted
13:47:57 <oedipus> SP: pasted pointer to breakout session described above into IRC
13:48:07 <ShaneM> ShaneM has joined #xhtml
13:48:19 <Steven>
13:48:23 <oedipus> rrsagent, make minutes
13:48:23 <RRSAgent> I have made the request to generate oedipus
13:48:38 <oedipus> SP: day 2 hasn't been posted yet - Sam Ruby making minutes
13:49:25 <Zakim> -ShaneM
13:49:48 <Zakim> +ShaneM
13:50:03 <oedipus> TH (from cited post): "I would argue that common concept of a paragraph is quite different
13:50:03 <oedipus>  from that we currently use in the XHTML draft, and that we should
13:50:03 <oedipus>  change it so that it reflect the way a paragraph is normally understood
13:50:03 <oedipus>  by authors, namely the way it is currently defined in the XHTML 1.*
13:50:03 <oedipus>  series languages."
13:50:47 <oedipus> TH (via post): "Note that I do not in any way claim there are no need to render, for instance, a paragraph on the side of, or even around, a table. What I am saying is that the structure of a paragraph does not admit itself to contain a table, a pre, or even a blockquote. A list is an edge case, but should we allow this I suggest the creation of an inline list element type."
13:51:06 <oedipus> RM: P content model as defined in present draft cause anyone a problem
13:51:38 <oedipus> SP: background: when originally designing text part of XHTML2, had a number of comments about the P content model not matching what perception of P is
13:52:12 <oedipus> SP: P defined in HTML4x too simple - could not embed images or table in paragraph; request was for things embedded in P be part of content model
13:52:50 <oedipus> SP: current content model of P is an attempt to do that - represent as much as possible the context of the paragraph, but also attempt to avoid P nested in P - P nested in TABLE cannot have child P
13:53:15 <oedipus>
13:53:46 <oedipus> from current Editor's draft: "In comparison with earlier versions of HTML, where a paragraph could only contain inline text, XHTML2's paragraphs represent the concept of a paragraph, and so may contain lists, blockquotes, pre's and tables as well as inline text. Note however that they may not contain directly nested p elements."
13:53:52 <Steven> (PCDATA | Text | List | blockcode | blockquote | pre | table )*
13:54:20 <oedipus> GJR notes he has proposal to deprecate TABLE for layout/style as BLOCKQUOTE for that use was deprecated in HTML4x
13:55:22 <oedipus> SP: always been opinion of this WG; don't explicitly say "deprecated", but agree that TABLEs are TABLEs and stylesheets should be used for layout
13:55:51 <oedipus> SP: proposed TABLE role="presentation" doesn't undo the damage, in fact almost encourages it
13:55:59 <oedipus> GJR: strong agreement - wrong approach
13:56:17 <oedipus>
13:57:19 <oedipus> AC: no presentation - OBJECT should be used to embed video, audio, or presentation
13:57:42 <oedipus> AC: more like a user-modality for TABLE - agree with SP and GJR that layout tables should be banned
13:59:36 <oedipus> SP: understand TH's point of view - current model allows one to represent data in that way; there are also those who belive that a P can have an embeded table or list - content doesn't change because child of P - styling up to stylesheets; neither POV is disallowed - accomodates both- up to author to decide what to use
13:59:49 <oedipus> TH (from post) "But frankly I feel we have a problem. When humans communicate we do so  by agreeing on the of words - and various other things outside the  scope of this comment - so that when I say banana, you know its not an  orange of which I speak."
14:00:12 <ShaneM> zakim, who is here
14:00:12 <Zakim> ShaneM, you need to end that query with '?'
14:00:16 <ShaneM> zakim, who is here?
14:00:16 <Zakim> On the phone I see Roland, Gregory_Rosmaita, Markus, Steven, Alessio, Tina (muted), ShaneM
14:00:18 <Zakim> On IRC I see ShaneM, Tina, alessio, mgylling, Roland, Zakim, RRSAgent, Steven, oedipus, trackbot
14:00:25 <oedipus> tina?
14:00:29 <Tina> I am, but noise in office
14:00:44 <oedipus> tina, can you explain your proposed changes to P content model
14:00:57 <Tina> oedipus: certainly. We keep the one currently in use for HTML.
14:01:12 <oedipus> RM: would like more examples - if want P element with example and discussion of this issue - could do this way (compatible with past) or new way
14:01:37 <oedipus> SP: TH wants to exclude people who believe P is something different than what she is proposing
14:01:53 <oedipus> RM: irritating when have to change prose into a list
14:02:25 <oedipus> RM: if write normal english: ingredients are: a) , b), c), but cannot style as list because is prose list
14:02:33 <oedipus> RM: that is standard natural language usage
14:03:10 <Roland> ingredients are: a; b; c.
14:03:14 <oedipus> s/a) , b), c), / a) ; b) ; c);/
14:03:19 <oedipus> rrsagent, make minutes
14:03:19 <RRSAgent> I have made the request to generate oedipus
14:03:32 <oedipus> SP: including a list in P is perfectly valid
14:03:39 <oedipus> RM: examples would help
14:04:24 <oedipus> SP: opened a book "a case in point is blogs:" followed by list of 10 items; i content that in natural language usage that is a single paragraph, but HTML doesn't allow the list to be part of the P 
14:04:46 <oedipus> GJR: agree - whether list is prose or formatted as list, belongs to the P and should be inside the P
14:04:53 <alessio> +1
14:04:56 <Tina> A suggestion, as quoted from me, above would be to allow lists - possibly inline lists - but exclude other use.
14:05:05 <oedipus> RM: alternative: leave as is, insert 2 examples, and note asking for feedback
14:05:46 <oedipus> ACTION - Gregory: draft example of P with prose list and structural list
14:05:46 <trackbot> Sorry, couldn't find user - -
14:05:59 <oedipus> ACTION: Gregory - draft example of P with prose list and structural list
14:05:59 <trackbot> Created ACTION-65 - - draft example of P with prose list and structural list [on Gregory Rosmaita - due 2009-04-02].
14:06:59 <oedipus> tina, could you provide examples of other uses of P?
14:07:16 <oedipus> or a list of what you would exclude from the P content model?
14:07:19 <Tina> No, I don't see any reason to continue the discussion, in particular if we are speaking merging the two WGs - HTML 5 design principles, if memory serve, insist on backward compatibility. Until it decided whether to merge or not the discussion is moot.
14:07:39 <oedipus> RM: only one causing difficulty with P content model is TABLE
14:08:07 <oedipus> RM: list, blockquote, pre and table
14:08:13 <Steven> (PCDATA | Text | List | blockcode | blockquote | pre | table )*
14:08:16 <oedipus> GJR: why blockquote and not blockcode?
14:08:30 <oedipus> SP: blockcode is part of content model
14:08:44 <oedipus> RM: what is normative? DTD or spec?
14:08:51 <oedipus> SM: spec always wins
14:09:03 <oedipus> RM: where spec doesn't include blockcode, bug in DTD
14:09:12 <oedipus>
14:09:18 <oedipus> SM: no DTD for XHTML2
14:09:26 <oedipus> SP: not from DTD but modulariztion code
14:09:40 <oedipus> RM: still looking at what we pointed to originally
14:09:48 <oedipus> RM: list, blockquote, pre and TABLE
14:10:00 <oedipus> SP: english text is wrong - should also include blockcode
14:10:19 <oedipus> SP: module text at top is definitive version
14:10:45 <oedipus> RESOLVED: fix XHTML2 prose to include blockcode
14:11:05 <oedipus> SM: shouldn't be in text
14:11:08 <oedipus> SP: plus 1 to that
14:11:20 <oedipus> GJR: following wiser heads like a lemming
14:11:29 <oedipus> SM: no other element describes content model in prose
14:11:47 <oedipus> SP: point of english text is to explain diff between XHTML2's P and earlier versions
14:11:55 <oedipus> RM: simple link-back to definition would help
14:12:09 <oedipus> SP: need to get that automated by shane
14:12:31 <oedipus> SP: spec written as small files - by element or attribute, which then get put together in standard way
14:12:46 <ShaneM> It should read: In comparison with earlier versions of HTML, where a paragraph could only contain inline text, XHTML2's paragraphs represent a richer content model more consistent with the concept of a paragraph.
14:13:02 <oedipus> GJR: plus 1 to shane's proposal
14:13:18 <oedipus> RM: talk about attributes, but not content model
14:13:39 <oedipus> SM: talk about content model elsewhere - may need to reinforce in this module because so large
14:14:03 <oedipus> SM: proposed text
14:14:31 <oedipus> SP: is example of P with embedded UL in it
14:15:00 <oedipus> RM: in contrast to what was done in previous versions P /P UL /UL rather than P UL /UL /P
14:15:13 <oedipus> SM: mistake for us to include references as to how things used to be
14:15:35 <oedipus> RM: alternative today - P can contain lists; put side-by-side explaining can do either of these
14:15:36 <oedipus> SM: ok
14:16:58 <oedipus> proposed RESOLUTION: "In comparison with earlier versions of HTML, where a paragraph could only contain  inline text, XHTML2's paragraphs represent a richer content model more consistent with the concept of a paragraph"
14:17:18 <oedipus> RM: not sure need "more consistent" clause
14:17:27 <oedipus> proposed RESOLUTION: "In comparison with earlier versions of HTML, where a paragraph could only contain  inline text, XHTML2's paragraphs represent a richer content model consistent with the concept of a paragraph"
14:18:02 <oedipus> RM: richer content model of paragraph should be sufficient
14:18:16 <oedipus> proposed RESOLUTION: "In comparison with earlier versions of HTML, where a paragraph could only contain  inline text, XHTML2's paragraphs represent a richer content model.
14:18:59 <oedipus> RESOLVED: replace current explanation of P content model with "In comparison with earlier versions of HTML, where a paragraph could only contain  inline text, XHTML2's paragraphs represent a richer content model."
14:19:21 <Zakim> -Steven
14:19:22 <oedipus> rrsagent, make minutes
14:19:22 <RRSAgent> I have made the request to generate oedipus
14:19:26 <Zakim> -Gregory_Rosmaita
14:19:28 <Zakim> -Tina
14:19:29 <oedipus> rrsagent, stop log
14:19:29 <RRSAgent> I'm logging. I don't understand 'stop log', oedipus.  Try /msg RRSAgent help
14:19:31 <oedipus> rrsagent, stop
14:32:28 <Zakim> +Gregory_Rosmaita
14:32:59 <oedipus> TOPIC: Navigation
14:33:12 <oedipus> question: Do we really need four different types of lists in XHTML 2.0?
14:33:14 <alessio> zakim, code?
14:33:14 <Zakim> the conference code is 26634 (tel:+1.617.761.6200 tel:+ tel:+44.117.370.6152), alessio
14:33:21 <oedipus>
14:33:21 <oedipus>
14:33:22 <Steven> zakim, dial steven-617
14:33:23 <Zakim> ok, Steven; the call is being made
14:33:25 <Zakim> +Steven
14:33:35 <Zakim> +[IPcaller]
14:33:43 <alessio> zakim, IPcaller is Alessio
14:33:43 <Zakim> +Alessio; got it
14:33:50 <oedipus> zakim, who is here?
14:33:50 <Zakim> On the phone I see Roland, Steven, Markus, Gregory_Rosmaita, Alessio
14:33:51 <Zakim> On IRC I see ShaneM, Tina, alessio, mgylling, Roland, Zakim, RRSAgent, Steven, oedipus, trackbot
14:33:59 <Tina> oedipus: an exaggeration, surely.
14:34:31 <Zakim> +ShaneM
14:34:38 <Tina> My 2 whatsits: yes. We DO need a rich set of lists for various structures that needs to be marked up. I would propose we add an inline-list to the ones we have, plus, of course, a 'menu' or 'navigation'
14:35:01 <oedipus> current editor's draft definition of NL:
14:35:12 <oedipus> RM: do we need 4 kinds of list?
14:35:40 <oedipus> RM: discussed - fairly broad concept; item about elements versus attributes topic is related
14:35:45 <oedipus> RM: why did we create NL?
14:36:11 <oedipus> SP: in early days, 1 thing we did was observe web sites to identify things on web sites that represented concepts not represented in common HTML markup
14:36:32 <Zakim> -Markus
14:36:56 <oedipus> SP: one thing that we concluded was types of list purely for navigational purposes - semantic advantage (expecially from A11y POV) advantageous; developed before developed Role and RDFa
14:37:14 <oedipus> SP: new markup allows NL without new type of element]
14:37:27 <oedipus> SP: instead of NL, UL role="navigation"
14:37:54 <oedipus> RM: device independence group worked on this; large areas of page - are areas devoted to navigation 
14:38:05 <Tina> OL, not UL. This is still a rather dramatic conceptual change. Why would we want to do that - and, on the flipside, not then simply have ONE list?
14:38:06 <oedipus> RM: not catered for inside markup; navigation is important property
14:38:08 <Zakim> +Markus
14:38:20 <mgylling> mgylling has joined #xhtml
14:38:23 <oedipus> RM: difference from my POV is navigation is more than list
14:38:50 <oedipus> RM: HTML5 has NAVIGATION element - useful notion: can be more to navigation than items; headings (primary navigation, secondary navigation)
14:39:05 <oedipus> RM: would like to reframe converstation from NL to NAVIGATION section
14:39:14 <Roland> HTML5  :
14:39:20 <ShaneM> I agree with Steven that @role can be used to indicate that a section is related to navigation.
14:40:06 <oedipus> SP: definitely case that had proposal on table for NL but didn't find consensus in WG; made general decision to use elements for structuring and attributes for semantics; helps us fulfil many requests; if request is for semantics, answer should be use RDFa or Role and leave elements for marking up strcuture
14:40:13 <oedipus> RM: felt navigation was structure
14:40:31 <ShaneM> <section role="navigation">...</section>
14:40:34 <oedipus> SP: use SECTION role="navigation" is equivalent
14:40:53 <oedipus> SP: could also use UL role="navigation" or OL role="navigation"
14:41:05 <oedipus> SP: can be done by attaching role to SECTION or directly to list
14:41:11 <Tina> Have we agreed to leave *all* semantics to RDFa and @role?
14:41:29 <ShaneM> Tina: No, I don't think so.
14:41:36 <oedipus> RM: OL role="navigation" equals SECTION role="navigation"
14:42:14 <oedipus> SP: MarkB would say NL wrong because makes list with specific semantic meaning; sturcture is ordered list and structure is navigation; if want section on navigation, use SECTION role="navigation"
14:42:22 <Tina> ShaneM: that begs the question - which semantics do we leave to elements? We already have three different list types. If they are there for structure only, then why don't we simplify and make one?
14:42:46 <oedipus> SM: context - state of art when introduced NL in visual user agent wasn't possible without heavy scripting; but today, that can be achieved with CSS
14:42:51 <oedipus> SM: throw out NL
14:42:54 <oedipus> SP: can live with that
14:42:57 <oedipus> AC: me too
14:42:59 <oedipus> GJR: me too
14:43:03 <mgylling> +1
14:43:05 <ShaneM> Note that @role already has a predefined value for "navigation"
14:43:18 <oedipus> RM: would prefer a NAV element rather than just list
14:43:56 <oedipus> RM: no element whose specific role is navigation, can be satisfied by assigning role to other structural elements
14:44:37 <oedipus> SP: kept a lot of elements that aren't strictly necessary because of use-and-practice with list
14:44:46 <oedipus> SM: extended content model for DL by adding DI
14:44:51 <oedipus> SM: very positive move
14:45:14 <oedipus> SM: can't decide if TH making serious point or playing devil's advocate
14:45:16 <Steven> zakim, who is on the phone?
14:45:16 <Zakim> On the phone I see Roland, Steven, Gregory_Rosmaita, Alessio, ShaneM, Markus
14:45:18 <oedipus> zakim, who is here?
14:45:19 <Zakim> On the phone I see Roland, Steven, Gregory_Rosmaita, Alessio, ShaneM, Markus
14:45:21 <Zakim> On IRC I see mgylling, ShaneM, Tina, alessio, Roland, Zakim, RRSAgent, Steven, oedipus, trackbot
14:46:04 <oedipus> SM: appreciate that there is a significant presentational and semantic difference between OL, UL, and DL - DT and DD need to be grouped in order to make sense
14:46:19 <oedipus> SM: don't think a lot of value removing things people are already familiar with
14:46:31 <Tina> It is a serious point in so far as we need to be consistent in where we leave semantic interpretation on element types, and where we move it to roles. Right now the draft is a little bit of this and a little bit of both. If we say that "The markup is for structure" as a general rule then we need only one list structure and extended @role values.
14:46:46 <oedipus> SM: does beg the question: "does it make sense for us to do things in language that we know will not work right in existing UAs?"
14:47:00 <oedipus> RM: not on agenda, but could discuss when return to HTML5 discussion
14:47:16 <oedipus> RM: making incremental changes that make it hard to deploy - is it worth return on investment
14:47:29 <oedipus> RM: do we need to introduce DI type of thing to discuss later
14:47:35 <oedipus> RM: concrete example?
14:47:35 <Tina> Since we are already changing or removing things people are already familiar with. Consistency is key.
14:47:45 <oedipus> SP: resolution to remove NL?
14:48:02 <oedipus> proposed RESOLUTION: remove NL from XHTML2's List Module
14:48:08 <oedipus> RM: propose we remove NL
14:48:12 <Steven> and replace with use of @role="navigation"
14:48:20 <oedipus> GJR: plus 1 with SP's caveat
14:48:26 <Steven> as necessary
14:48:53 <oedipus> SM: we created "navigation" role
14:49:15 <oedipus> proposed RESOLUTION: remove NL from XHTML2's List Module and replace with use of role="navigation"
14:49:29 <oedipus> SP: current model for DL wouldn't break existing user agents
14:49:38 <Steven> I think
14:49:44 <oedipus> GJR: agree with SP - will make DL stronger and more useful
14:49:44 <Steven> +1
14:49:47 <Steven> on resolution
14:49:53 <mgylling> +1
14:49:54 <oedipus> proposed RESOLUTION: remove NL from XHTML2's List Module and replace with use of role="navigation"
14:49:59 <oedipus> plus 1
14:50:05 <ShaneM> Tina: I think there is a (new) trend toward NOT removing things that people are familiar with.
14:50:09 <ShaneM> oops...
14:50:51 <oedipus> definition of navigation from vocab document: "navigation indicates a collection of items suitable for navigating the document or related documents."
14:51:35 <oedipus> RM: seem to have gotten a bit mixed up - talking about multiple things
14:51:40 <oedipus> RM: resolution to remove NL
14:51:44 <oedipus> proposed RESOLUTION: remove NL from XHTML2's List Module and replace with use of role="navigation"
14:51:52 <ShaneM> +1
14:51:52 <Roland> +1
14:51:54 <Steven> +1
14:51:55 <alessio> +1
14:52:00 <oedipus> RESOLVED: remove NL from XHTML2's List Module and replace with use of role="navigation"
14:52:04 <oedipus> rrsagent, make minutes
14:52:04 <RRSAgent> I have made the request to generate oedipus
14:52:16 <ShaneM> ACTION: Shane to remove the nl element from XHTML 2
14:52:16 <trackbot> Created ACTION-66 - Remove the nl element from XHTML 2 [on Shane McCarron - due 2009-04-02].
14:52:46 <oedipus> SM: one related item is DL 
14:52:53 <oedipus> SP: changes won't change deployment
14:52:58 <oedipus> SM: DI would be ignored?
14:53:04 <oedipus> MG: DI is optional
14:53:16 <oedipus> GJR: provides nice low-grade binding for DDs
14:53:35 <oedipus> RM: DI introduced to solve what particular problem?
14:53:55 <oedipus> "Definition lists vary only slightly from other types of lists in that list items consist of two parts: a term and a description. The term is given by the dt element. The description is given with a dd element. The term and its definition can be grouped within a di element to help clarify the relationship between a term and its definition(s)."
14:54:53 <mgylling> ... di solves a problem that could also be solved with @for...
14:55:30 <oedipus> SP: if 2 things are related, DI can express that; presentation: hard to put border around DT and DD; from semantic POV want them to be joined at head and not hip
14:55:47 <oedipus> markus, do you have more to say on "for" 
14:56:09 <oedipus> RM: like paragraph - if don't want to use DI, don't have to
14:56:13 <mgylling> no - I am all for DI. 
14:56:18 <oedipus> good
14:56:32 <oedipus> RM: any other potential pitfalls with lists?
14:57:05 <oedipus> SM: added in list module the caption element and hooked into content model for all lists
14:57:07 <ShaneM>
14:57:08 <oedipus>
14:57:22 <oedipus> RM: lists allow caption
14:57:33 <oedipus> GJR: might want to consider LEGEND
14:59:12 <Steven> We need to consider the purposes of LEGEND LABEL and CAPTION
14:59:21 <oedipus>
14:59:22 <Steven> and work out whether to merge
14:59:42 <alessio> yes, it's a very good point
15:00:09 <oedipus> SM: haven't addressed use of XForms inline content with other forms of inline content
15:00:23 <oedipus> Use of FIGURE, LEGEND, and @alt
15:00:23 <oedipus> Three Stages of A Butterfly's Life Example
15:00:23 <oedipus> Each of the images in the 3 stages of a butterfly's life REQUIRE alt text and/or labelledby to provide them with unique and appropriate short descriptions, just as each form control in a FIELDSET has its own LABEL defined for it, with the value of the LEGEND element providing a CAPTION-like function for the FIELDSET, so too does LEGEND provide a means of declaratively marking explicit bindings of groups of related objects, as in:
15:00:30 <oedipus> <FIGURE aria-labelledby="l1">
15:00:30 <oedipus> <LEGEND id="l1">The Three Stages of a Butterfly's Life Cycle</LEGEND>
15:00:30 <oedipus> <IMG alt="Stage 1: The larval stage." src="butterfly1.svg" 
15:00:30 <oedipus>      longdesc="butterfly1.html">
15:00:30 <oedipus> <IMG alt="Stage 2: The pupal stage." src="butterfly2.svg" 
15:00:33 <oedipus>      longdesc="butterfly2.html">
15:00:35 <oedipus> <IMG alt="Stage 3: The adult stage." src="butterfly3.svg" 
15:00:36 <oedipus>      longdesc="butterfly3.html">
15:00:39 <oedipus> </FIGURE>
15:00:41 <oedipus> the LEGEND applies to all three images as a collection of related objects, available, for example, in a screen reader situation, either through a verbosity setting or via an extended query, such as MagicKey+TAB reads the alt text of the individual graphic which has focus, MagicKey+TAB pressed twice rapidly (or with a moderator key) provides the user with the LEGEND which describes, tersely, the group to which the individual image belongs, so that the user can b
15:00:47 <oedipus> a) each individual image's short alternative text;
15:00:48 <oedipus> b) the grouping to which the image belongs (if it is one of a series presented in a FIGURE) or any other modality-specific content contained in HTML5's media-specific elements, including AUDIO, VIDEO, OBJECT and CANVAS;
15:01:03 <oedipus> TOPIC: Supplemental Document - Best Practices Guide?
15:01:51 <oedipus> RM: need to orient readers and contextualize use of XHTML2 to alter content and improve usability of content - how to pull pieces of m12n together
15:02:39 <oedipus> GJR: i will send "thoughts on LEGEND" used in PF deliberations over terse descriptors in HTML5 to XHTML2 list
15:02:57 <oedipus> RM: like examples - pick up as a template and build upon it
15:03:33 <oedipus> RM: christina once worked on something similar, but we haven't undertaken anything as a WG
15:03:38 <oedipus> SP: no, we haven't really
15:03:58 <oedipus> RM: continuing developing document, steven?
15:04:01 <Roland> Roland has left #xhtml
15:04:14 <oedipus> SP: received a lot of feedback at AC meeting on how should be structured
15:04:21 <Roland> Roland has joined #xhtml
15:04:26 <oedipus> rrsagent, make minutes
15:04:26 <RRSAgent> I have made the request to generate oedipus
15:04:31 <Steven> s/feedback/input/
15:05:06 <oedipus> rrsagent, make minutes
15:05:06 <RRSAgent> I have made the request to generate oedipus
15:05:30 <oedipus> TOPIC: how to incorporate ITS
15:05:36 <oedipus>
15:05:36 <oedipus>
15:05:52 <oedipus> SM: does anyone understand the ITS question?
15:06:34 <oedipus> SP: background: googletranslate - when automatically translates page, ITS helps markup page to assist process; when i say "window" don't translate because is technical term; 
15:07:01 <oedipus> SP: semantic markup with specific domain: meaning of words with respect to other languages
15:07:17 <mgylling>
15:07:36 <oedipus> RM: who is driving this request
15:07:41 <oedipus> SP: i18n
15:08:15 <Steven> Then from there, run batch file <cmd
15:08:15 <Steven>      its:translate="no">Build.bat</cmd>.</p>
15:08:29 <oedipus> MG: investigated ITS - 3 options to introduce rules into document - inline (similar to @style), xlink to external document, or put info in HEAD
15:08:44 <oedipus> MG: not just question of attribute, but should we support XLINK in HEAD, etc.
15:08:54 <oedipus> RM: can link to ITS definition, full stop
15:08:57 <oedipus> SM: not an option
15:09:05 <oedipus> SP: wouldn't let us do that?
15:09:22 <oedipus> SM: our architecture doesn't allow for arbitrary content models; need to specificy what goes where
15:09:56 <oedipus> SM: ITS was on rec track; asked us to do LC review; we said fine, but forgot M12n; listened to us and produced modules and went to REC
15:10:30 <oedipus> SM: should we incorporate into XHTML 1.2 - no, but i was given action item to put into XHTML2 - too many options, need to pick one
15:10:43 <oedipus> SM: should ask ITS WG how to use ITS in our module
15:10:48 <oedipus> RM: ITS WG closed
15:10:56 <oedipus> RM: ITS interest group still active
15:11:10 <oedipus> RM: should ping them to ask "how do you think this applies to us?"
15:11:24 <oedipus> SP: created something similar to CSS - create rules in HEAD or inline
15:11:50 <oedipus> SP: a lot of their stuff we have anyway - don't need @dir because took from us and put in their namespace
15:12:06 <oedipus> GJR: notes that this is a good trend - similar to timesheets
15:12:34 <oedipus> SP: translate rules - include their rules into HEAD and then in BODY only thing that is left is translate equals yes or no
15:12:53 <oedipus> MG: correct; have schema modules for ITS we can import
15:13:02 <oedipus> MG: external sheets via XLink
15:13:15 <oedipus> MG: should ask if can use LINK element instead
15:13:19 <oedipus> RM: sounds reasonable
15:13:52 <oedipus> SP: invite someone from ITS to join us on a call to discuss
15:14:06 <oedipus> GJR: sounds reasonable
15:14:17 <oedipus> SP: should be able to find someone courtesy of RichardI
15:14:47 <oedipus> ACTION: Steven - talk to Richard to ask if someone from ITS can join an XHTML2 call to discuss this further
15:14:47 <trackbot> Created ACTION-67 - - talk to Richard to ask if someone from ITS can join an XHTML2 call to discuss this further [on Steven Pemberton - due 2009-04-02].
15:15:00 <oedipus> RM: is anyone recognizing ITS?
15:15:12 <oedipus> SP: if no one is producing content with it answer is no
15:15:26 <oedipus> RM: are we the best people to bootstrap this?
15:15:48 <oedipus>
15:16:00 <oedipus>
15:16:10 <oedipus>
15:17:28 <oedipus> SM: should be bending over backwards to reuse W3C technologies and standards
15:17:52 <oedipus> GJR: first principle of WCAG - if pertinent technology exists (such as MathML) use it
15:18:01 <Steven> r12a suggests �10 �01yves savourel �01chair of the former WG
15:18:02 <oedipus> RM: doesn't sound too onerous
15:18:07 <Steven> and cc to Felix of W3C
15:18:47 <oedipus> RM: don't need its prefix, just "yes" or "no"
15:18:55 <oedipus> SM: does spec allow chameleon?
15:19:38 <oedipus> MG: published note on how to incorporate ITS into XHTML family
15:19:57 <oedipus>
15:20:10 <Steven> ysavourel at
15:20:14 <oedipus> processing expections for ITS:
15:20:25 <Roland>
15:20:46 <oedipus>
15:20:55 <oedipus>
15:21:12 <oedipus> "Three such markup schemes are described in section ITS Applied to Existing Formats of the latest public Working Draft of Best Practices for XML Internationalization: ITS and TEI, ITS and XHTML 1.0, and ITS and XML Spec. In response to comment Please use XHTML Modularization for defining ITS DTD and Schema, the Working Group has defined an ITS module for XHTML, using the XHTML modularization framework."
15:21:27 <oedipus> MG: roland's pointer the one i was thinking about
15:21:35 <oedipus> SM: last one GJR put in is what i was looking at
15:21:53 <oedipus> RM: XHTML M12n 1.1 -
15:22:45 <oedipus> SM: our treatment of schema allows us to bring in elements and attributes from other namespaces; don't have to include in our namespace if already exists elsewhere and is in use
15:23:40 <oedipus> "1) ITS and TEI: ITS rules is allowed to appear in the TEI metadata section (the teiHeader). The local ITS attributes are added to the global attribute set for all elements. ITS span is added to the content pattern model.common (most inline contexts)."
15:23:40 <oedipus> "2) ITS and XHTML 1.0: ITS rules is allowed to appear in the XHTML head element (the group HeadOpts.mix has been redefined accordingly). The local ITS attributes are added to the global attribute set for all elements (the group Common.attrib has been redefined accordingly). Ruby is not used since the ruby specification already defines an XHTML module for ruby."
15:23:40 <oedipus> "3) ITS and XML Spec: ITS rules is allowed to appear in the XML Spec header element (rules has been added as the last element to the XML Spec entity header.mdl). The local ITS attributes are added to the global attribute set for all elements (they have been added to the entity common.att). ITS ruby is allowed to appear as an inline element (it has been added to the entity p.pcd.mix)."
15:26:18 <oedipus> SP: reading from spec: "one way to associate document with external ITS rules is to use optional XLINK"
15:27:16 <oedipus>
15:27:41 <Steven> so it sounds optional
15:27:49 <oedipus> SM: questions we have: don't support XLink, so can we use LINK?  leave in ITS space and use their suggested model?
15:28:23 <oedipus> SM: inclination is to invite someone to discuss XLink - for content model, take what proposed for XHTML 1.1 leave in ITS namespace and do what they said
15:28:57 <oedipus> proposed RESOLVED: XHTML2 WG will discuss ITS integration and use of LINK versus XLink with representative from i18n
15:29:06 <oedipus> RESOLVED: XHTML2 WG will discuss ITS integration and use of LINK versus XLink with representative from i18n
15:29:10 <oedipus> SP: already invited them
15:29:12 <oedipus> SM: thank you
15:29:21 <oedipus> rrsagent, make minutes
15:29:21 <RRSAgent> I have made the request to generate oedipus
15:29:38 <oedipus> RM: anything else on ITS?
15:30:18 <oedipus> TOPIC: Clearing Out Old Action Items
15:30:24 <oedipus> RM: quantity values question
15:31:24 <oedipus> SP: when we have href type and src type which allows one to define what values are suitable; in HTML4 have type on HREF - comment that says what is on other end - just a claim, not firm basis for content negotiation
15:31:40 <oedipus> SP: in XHTML2 have list of types used for content negotiation
15:32:27 <oedipus> SP: comment that don't take into account QValues
15:32:53 <oedipus> SP: been boning up on QValues
15:33:28 <oedipus> RM: should add to traker
15:33:36 <oedipus> s/traker/tracker
15:34:34 <oedipus> SP: if say "here is an image" may be in 10 diff formats, but want SVG or PNG to be first choice, if user agent can't handle SVG or PNG, have to provide something UA says can accept
15:35:14 <oedipus> SP: answer may be no qvalues in source
15:35:19 <oedipus> SM: think that is the answer
15:35:38 <oedipus> SM: QValue responsibility of UA; intersection of what UA wants and what author can offer
15:35:55 <oedipus> s/what UA wants/what UA can handle/
15:36:10 <oedipus> SP: order of things in specification important - take first or highest q?
15:36:33 <oedipus> SP: when UA specifies what is willing to accept does it mean willing to accept them equally
15:36:38 <oedipus> SM: have to check HTTP spec
15:36:48 <oedipus> SM: order is probably significant - will check
15:38:10 <Steven> ACTION: Steven to work out how to merge q values in the specification of content negotiation with hreftype etc.
15:38:10 <trackbot> Created ACTION-68 - Work out how to merge q values in the specification of content negotiation with hreftype etc. [on Steven Pemberton - due 2009-04-02].
15:38:52 <oedipus>;statetype=-1;upostype=-1;changetype=-1;restype=-1
15:39:26 <oedipus> RM: work through 16 open issues on shane's tracker?
15:39:28 <oedipus> SM: not now
15:39:31 <oedipus> RM: when?
15:39:46 <oedipus> SM: not sure what to do with 5 year old comments
15:39:54 <oedipus> RM: are any of the issues still relevant?
15:40:22 <oedipus> RM: how to deal with them?
15:40:35 <oedipus> GJR: port them to W3C tracker and close those that are moot?
15:41:11 <oedipus> "QNames are the way that the working group, and indeed the W3C, handle having
15:41:11 <oedipus> data that comes from differing sources. The working group is not willing to
15:41:11 <oedipus> change course at this time
15:41:32 <oedipus> SM:;user=guest;statetype=-1;upostype=-1;changetype=-1;restype=-1 needs to be split up 
15:41:37 <oedipus> SP: some just comments
15:41:46 <oedipus> SP: several of these things don't need to do
15:41:58 <oedipus> SP: can answer, but no action necessary
15:42:07 <oedipus> SP: real issues: keep BR (which i think we do)
15:42:15 <oedipus> SM: were instructed by TBL to keep BR
15:42:32 <oedipus> SP: a lot of editorial comments
15:43:03 <Tina> What is the structural purpose of BR? That should be the only reason why we keep it or toss it.
15:43:42 <Tina> Yes. What's our use case for keeping it?
15:43:49 <oedipus> SP: could say that WG received this remark and is not required to answer; get input from more recent suggestions
15:44:35 <Zakim> -Gregory_Rosmaita
15:44:45 <Tina> Then I suggest we get rid of BR as more-or-less physical markup.
15:44:57 <Zakim> -Steven
15:45:52 <Zakim> -Alessio
15:46:16 <Zakim> +Gregory_Rosmaita
15:46:45 <oedipus> tina, do you want to work on a proposal to eliminate BR?
15:47:06 <oedipus> deprecate in favor of use of L ... /L
15:48:18 <oedipus> anne van k on L: "Didn't BLOCKCODE preserve whitespace by default? What do we need the L 
15:48:18 <oedipus> element for here? And as mentioned before, BR is still needed. I also 
15:48:18 <oedipus> think that a better use case for L should be presented, this one is bad."
15:48:28 <Tina> oedipus, I don't have the time to write up anything formal, I'm afraid.
15:48:44 <oedipus> me neither, but i might as well take a whack at it right now
15:50:44 <oedipus> GJR's take: BR is a presentational concept; to express that a line of content is intended to be interpreted as single line of content, authors should use the L element to mark the beginning and end of a line.
15:50:51 <oedipus> zakim, who is here?
15:50:52 <Zakim> On the phone I see Roland, ShaneM, Markus, Gregory_Rosmaita
15:50:55 <Zakim> On IRC I see Roland, mgylling, ShaneM, Tina, alessio, Zakim, RRSAgent, Steven, oedipus, trackbot
15:51:48 <Steven> zakim, dial steven-617
15:51:48 <Zakim> ok, Steven; the call is being made
15:51:50 <Zakim> +Steven
15:51:56 <oedipus> RM: keep differences from status-quo to a minimum - makes easier to deploy in existing browsers
15:52:27 <Tina> oedipus: I agree with that.
15:52:36 <oedipus> SM: "1.1.2. Backwards compatibility
15:52:50 <oedipus> SM: will update as appropriate
15:53:00 <oedipus> SM: 1.1.2. Backwards compatibility
15:53:06 <Tina> We are already deviating from that, however, by changing content models. Removing presentational markup is surely a good idea.
15:53:14 <oedipus> SM: wants BR back; instructed to do it, but haven't done it
15:53:16 <oedipus> q+
15:53:22 <oedipus> GJR's take: BR is a presentational concept; to express that a line of content is intended to be interpreted as single line of content, authors should use the L element to mark the beginning and end of a line.
15:53:53 <oedipus> SM: agree
15:54:31 <oedipus> RM: back to pragmatic - authors need to understand what to do - how much benefit from being purists, how much from being practical - can we live with either or
15:54:48 <oedipus> SP: can live with keeping it, but with a note stating that L is preferred method
15:54:59 <oedipus> ack oe
15:55:03 <ShaneM> ACTION: Shane to put br element back into XHTML 2 with a note that there are better ways to mark up lines.
15:55:03 <trackbot> Created ACTION-69 - Put br element back into XHTML 2 with a note that there are better ways to mark up lines. [on Shane McCarron - due 2009-04-02].
15:55:20 <oedipus> proposed Resolution: restore BR
15:55:25 <oedipus> SP: objections?
15:55:27 <oedipus> GJR: object
15:55:42 <oedipus> SP: if objections, don't have resolution
15:56:48 <oedipus> RM: GJR, do you believe we should not do this?
15:57:23 <Zakim> +??P3
15:57:29 <alessio> zakim, ??P3 is Alessio
15:57:29 <Zakim> +Alessio; got it
15:57:32 <oedipus> GJR: willing to compromise on BR if we add note on use of L
15:58:00 <Tina> I see no good reason to put a presentational element back in. This isn't as much about pragmatic solutions - CSS can do the visual if need be.
15:58:08 <oedipus> GJR: is there any override mechanism for BR?
15:58:23 <oedipus> SP: compromise: include BR but mark as deprecated
15:58:25 <oedipus> GJR: yes
15:58:40 <ShaneM> deprecated?  in a legacy br module?
15:58:52 <oedipus> proposed RESOLUTION: re-introduce BR, marking as deprecated, and point out that for accessibility, is much  better to use L
15:59:02 <Steven> +1
15:59:07 <ShaneM> +1
15:59:07 <oedipus> GJR: plus 1
15:59:16 <oedipus> AC: yes
15:59:18 <Roland> +1
15:59:19 <mgylling> +1
15:59:21 <alessio> +1
15:59:27 <oedipus> RESOLVED: re-introduce BR, marking as deprecated, and point out that for accessibility, is much  better to use L
15:59:33 <oedipus> rrsagent, make minutes
15:59:33 <RRSAgent> I have made the request to generate oedipus
16:01:37 <oedipus> RM: next one is ADDRESS element
16:02:01 <oedipus> SM: request is make content model for address richer, or introduce a BLOCKADDRESS element
16:02:12 <oedipus> GJR: isn't this covered by role="contentinfo"
16:02:39 <oedipus> vocab doc: "
16:02:39 <oedipus>     contentinfo has meta information about the content on the page or the page as a whole.
16:03:01 <Steven> By the way, there is a new rrsagent in the works:
16:03:13 <oedipus>
16:03:31 <oedipus> SM: not inclined to change from block to inline or to add blockaddress
16:03:41 <oedipus> SP: non-structural element that only adds semantic information
16:03:56 <oedipus> SP: semantic info is terribly vague - can't extract much sensible out of ADDRESS
16:04:15 <oedipus> RM: HTML5's ADDRESS is not block
16:04:55 <oedipus> SM: problem is content model restricted; 
16:05:09 <oedipus>
16:05:38 <oedipus> 'The address element represents the contact information for the section it applies to. If it applies to the body element, then it instead applies to the document as a whole"
16:06:07 <Tina> That does appear fairly clear, if not detailed. What is the use case for changing it?
16:06:15 <oedipus> "The address element must not contain information other than contact information."
16:06:27 <ShaneM> Tina: the request is to make the content model richer
16:07:02 <oedipus> GJR: HTML5 Address is a child of FOOTER
16:07:07 <Tina> If so, do we need to change the element or simply add other elements which go inside it that allows an author to define up the various pieces?
16:07:09 <oedipus>
16:07:51 <oedipus> GJR: address is part of FOOTER, but restricted to contact info onlly
16:07:58 <oedipus> s/onlly/only
16:08:05 <oedipus> GJR: in HTML5
16:08:29 <ShaneM> Tina: I think we just could make the content model richer.
16:09:07 <oedipus> Content model for FOOTER in HTML5: "Flow content, but with no heading content descendants, no sectioning content descendants, and no footer element descendants."
16:09:45 <oedipus> SM: either add blockaddress or fix rich content model
16:09:56 <oedipus> SM: objections to making content model of ADDRESS richer?
16:10:01 <oedipus> SM: need to define "richer"
16:10:11 <oedipus> SM: same as SECTION
16:10:13 <Tina> ShaneM: not a bad idea. We can keep ADDRESS, then add various elements for marking up specific sections of contact info. Or rely on namespaces for people to use elements from other XMLs.
16:10:21 <oedipus> RM: why not say SECTION role="address"
16:10:54 <oedipus> SP: on other hand, could just say ADDRESS is shorthand for SECTION role="address"
16:11:08 <oedipus> RM: no difference in semantics for ADDRESS and SECTION role="address"
16:11:17 <oedipus> RM: need to define semantics of ADDRESS
16:11:47 <oedipus> SM: DIV role="p" is not a substitute for using P - if element has semantics, use the element
16:12:27 <oedipus> SM: have ADDRESS element - could say "if need area of document with richer content model and address information, use SECTION role="address"
16:12:35 <oedipus> RM: no existing "address" role
16:13:06 <oedipus> GJR: when we did ARIA/HTML5 analysis decided that "contentinfo" more broad than HTML's ADDRESS
16:13:27 <oedipus> SM: defer to dublin core or VCard?
16:13:45 <Tina> Suggestion: keep <address> as is, and encourage authors to use other markup languages for the specifics.
16:13:52 <oedipus> SM: vocab collection for role is missing fundamental concepts - is that because we are deferring to DC
16:13:59 <oedipus> SP: do in RDFa instead of role
16:14:20 <oedipus> RM: on typical page, navigation area, content area, contact area very common - address related to contact info
16:14:29 <oedipus> SM: dublin core values we can use for that
16:14:42 <oedipus> RM: broke up page into appendix, content, copyright, etc.
16:15:02 <oedipus> SM: can add a role
16:15:35 <alessio> agree
16:15:38 <oedipus> RM: can state "not changed from HTML4; if want richer mechanism, create it according to the markup family's extension rules
16:15:49 <oedipus> SM: probably way to group all of this together
16:16:03 <oedipus> SM: should we introduce additional role values
16:16:05 <oedipus> GJR: yes
16:16:08 <oedipus> SP: good point
16:16:31 <oedipus> GJR: would like to differentiate between explanatory note and referential note
16:16:58 <oedipus> SM: in existing vocabulary
16:17:32 <oedipus> from vocab document: note: "note indicates the content is parenthetic or ancillary to the main content of the resource."
16:18:06 <oedipus> GJR: there are 2 types of note: referential (citation, endnote) and annotative (what the vocab doc says)
16:18:27 <oedipus> SP: resolution?
16:18:51 <ShaneM> Tina: I think that is where we are ending up.  Thanks!
16:18:52 <oedipus> RM: leave address as-is, if want to create richer structures for that information, use SECTION
16:19:40 <oedipus> proposed RESOLUTION: leave ADDRESS as-is, add note that if author wants to create richer structures for that information, author can do so following langauge's extension mechanism (e.g. use SECTION)
16:20:04 <alessio> +1
16:20:07 <ShaneM> +1
16:20:09 <oedipus> proposed RESOLVED: leave ADDRESS as-is, add note that if author wants to create richer structures for that information, author can do so following langauge's extension mechanism, e.g. use SECTION
16:20:13 <Roland> +1
16:20:23 <oedipus> RESOLVED: leave ADDRESS as-is, add note that if author wants to create richer structures for that information, author can do so following langauge's extension mechanism, e.g. use SECTION
16:20:36 <oedipus> SM: need to discuss additional role values - add to next f2f agenda
16:20:41 <oedipus> rrsagent, make minutes
16:20:41 <RRSAgent> I have made the request to generate oedipus
16:21:16 <oedipus> SM: heading element - "confusing" - example of use of both 
16:21:27 <oedipus> SM: think addressed this by moving things around in document
16:21:45 <oedipus> SM: anne objects to P element content model that allows some block-level elements to be mixed in
16:22:12 <oedipus> GJR: reminder earlier RESOLUTION: replace current explanation of P content model with "In comparison with earlier versions of HTML, where a paragraph could only contain inline text, XHTML2's paragraphs represent a richer content model."
16:22:21 <oedipus> SM: PRE element comments
16:22:32 <oedipus> SM: changed example
16:22:46 <oedipus> GJR: PRE is a problem for accessibility
16:23:01 <oedipus> RM: editorial comment
16:23:19 <oedipus> SM: separator element - 
16:23:44 <oedipus> SP: TBL has affection for HR
16:23:57 <Steven> unexplained affection
16:24:04 <Tina> Do we need HR when we have SECTION?
16:24:08 <oedipus> "There isn't mentioned a single use case. Only some presentational issues 
16:24:08 <oedipus> that should be kept in CSS as mentioned in 1.1.1. Right?"
16:24:17 <Steven> no TIna, we don't
16:24:31 <oedipus> SM: don't understand point of comment
16:24:47 <oedipus> GJR: hell, lets deprecate all BLOCK* elements in favor of CSS
16:25:16 <oedipus> SM: lets disucss separator
16:25:43 <oedipus> SM: TBL has affection for HR - does that mean need HR deprecated in favor of SEPARATOR?
16:25:59 <oedipus>
16:26:35 <oedipus> SP: from fundamental point of view, solves problems with HR - found use cases for separator, could do with SECTION, but SEPARATOR is useful markup
16:27:13 <oedipus> SP: problem with HR - presentational; rather than introduce VR, use SEPARATOR
16:27:40 <oedipus> RM: should say HR has no semantic meaning but is shorthand for SEPARATOR
16:28:12 <oedipus> proposal: rename SEPARATOR to HR and add note: "there is nothing horizontal or presentational implied by HR"
16:28:22 <oedipus> SP: first element not related to concept
16:28:49 <oedipus> RM: should be there for legacy, but if starting afresh use SEPARATOR
16:29:22 <oedipus> SP: reason for caring is that saying that won't change ingrained understanding of HR no matter what we say
16:29:41 <oedipus> RM: how do languages that want VR handle HR?
16:29:43 <Zakim> -Markus
16:30:15 <oedipus> SP: maybe HR only works horizontally and are using borders on DIV for visually approximations of vertical rules
16:30:27 <oedipus> SP: i18n complaint still valid
16:30:28 <Zakim> +Markus
16:30:44 <oedipus> RM: only if say HR has semantic meaning other than as shorthand for SEPARATOR
16:31:29 <oedipus> SP: have to provide standard stylesheet for XHTML2 - have to provide default style for SECTION, H, etc.
16:31:50 <oedipus> SM: don't think SEPARATOR an HR
16:32:02 <oedipus> SM: HR is a styled line running horizontally across page
16:32:26 <oedipus> SM: separator is semantic indication that one part of document different from another - can be reflected in style rules or not
16:33:06 <oedipus>
16:33:22 <oedipus> HTML5: "The hr element represents a paragraph-level thematic break, e.g. a scene change in a story, or a transition to another topic within a section of a reference book."
16:33:48 <oedipus> RM: suggest we move on for now
16:34:26 <oedipus> "Contexts in which this element may be used: Where flow content is expected."
16:35:06 <oedipus> SM: next comment: ABBR should use something other than @title - we do, so that is moot
16:35:12 <oedipus> SM: next comment: CITE element
16:35:28 <oedipus>
16:36:09 <oedipus> "Precis: In XHTML2, any element may have a href attribute. Since href is global, would it not be logical to mandate use of the href attribute in those circumstances where the cite attribute is currently used: as a consistent means of pointing at a resource, thereby providing the author with a linking mechanism that endows the user with the possibility of reviewing the quote in context. Therefore, it is proposed that the cite attribute be redefined to contain hu
16:37:20 <oedipus> <section role="main">
16:37:20 <oedipus> <q for="fdr3i" 
16:37:20 <oedipus> href=""
16:37:20 <oedipus> cite="Franklin Delano Roosevelt: Third Innaugural Address; January 20, 1941"
16:37:20 <oedipus> >In the face of great perils never before encountered, our strong 
16:37:21 <oedipus> purpose is to protect and to perpetuate the integrity of democracy.
16:37:23 <oedipus> </q>
16:37:24 <oedipus> <!-- ... -->
16:37:26 <oedipus> </section>
16:37:28 <oedipus> <section role="secondary">
16:37:31 <oedipus> <h id="biblio">Bibliography</h>
16:37:33 <oedipus>  <ol>
16:37:34 <oedipus>    <li role="contentinfo"><cite id="fdr3i" 
16:37:36 <oedipus>    src=""
16:37:39 <oedipus>    >Roosevelt, Franklin Delano. Third Inaugural Address. Delivered 
16:37:40 <oedipus>    before a joint session of congress, January 20, 1941. (official 
16:37:42 <oedipus>    White House transcript)</li>
16:37:44 <oedipus>  </ol>
16:37:46 <oedipus> <!-- ... -->
16:37:49 <oedipus> </section>
16:37:59 <oedipus> GJR: Finally, a for/id relationship between the Q element and the CITE element, which allows the author to bind individual quotes to a common source.
16:38:28 <Steven> I think this is another element rendered unecessary by rdfa
16:38:34 <oedipus> GJR: should be able to point to CITE element with for/id relationship
16:38:37 <Steven> s/une/unne/
16:38:59 <oedipus> GJR: if @cite is retained should be for human processing
16:39:18 <oedipus> SM: disagree
16:39:42 <oedipus> SM: src is used to identify external source that is only read-in; href is used for hyperlink; cite is something else
16:40:04 <oedipus> SM: in current XHTML2 @cite is an @href that is actionable through an alternate method
16:40:19 <oedipus> GJR: a quote is embedded content
16:40:41 <Steven> I think it is actually equivalent to rel="cite" href="...."
16:40:52 <ShaneM> <quote src="someURI" />
16:41:01 <alessio> yep
16:41:11 <oedipus> SM: @src brings in a URI and replaces Q
16:41:47 <oedipus> GJR: "Since href is global, would it not be logical to mandate use of the href attribute in those circumstances where the cite attribute is currently used: as a consistent means of pointing at a resource, thereby providing the author with a linking mechanism that endows the user with the possibility of reviewing the quote in context. Therefore, it is proposed that the cite attribute be redefined to contain human parseable information -- such as the source of a 
16:43:12 <oedipus> GJR: "Likewise, the globally available src attribute should be applied explicitly to the CITE element, so that an author can point to a standardized external reference profile for the resource encased in the CITE element. Finally, a for/id relationship between the Q element and the CITE element, which allows the author to bind individual quotes to a common source. "
16:43:40 <oedipus> SM: @cite is legacy - existed in HTML4; has different semantic than @href
16:43:48 <oedipus> SM: drop @src
16:43:58 <oedipus> SM: @href and @cite similar
16:44:07 <oedipus> SM: not sure how dovetails with RDFa
16:44:32 <oedipus> SM: arguable that @cite is something RDFa should process but didn't define rules for that
16:45:09 <oedipus> GJR: @href for Q points to content in context; @src for Q points to source of quote
16:45:13 <oedipus> SM: rel="cite"
16:45:32 <oedipus> s/SM: rel="cite"/SP: rel="cite"
16:45:39 <oedipus> SM: will bring up in RDFa telecon
16:47:21 <oedipus> "Currently, asssistive technologies are capable of speaking the contents of the cite attribute when one is reading a quote or blockquote and has quote identification turned on; however, the utility of a URL to provide context and continuity are exceedingly limited -- a URI should be the course of last resort. An example has been set by assistive technologies' handling of images: if no alt try title if no title, use the src value. For cite attribute, the cascade
16:47:55 <oedipus> cite in HTML4x
16:48:04 <oedipus> RM: are we done with AVK's comment on cite?
16:48:08 <oedipus> SM: fixed examples
16:48:18 <oedipus> SM: KBD element
16:48:34 <oedipus>
16:49:08 <oedipus> current XHTML2 wording: "The kbd element indicates input to be entered by the user."
16:49:21 <oedipus> SM: response: not in our scope
16:49:24 <oedipus> RM: agree
16:49:27 <oedipus> SP: agree
16:49:30 <oedipus> GJR: agree
16:49:31 <alessio> agree
16:49:36 <Zakim> -Steven
16:49:53 <oedipus> SM: AVK's next comment - use case for L is bad and doesn't BLOCKCODE preserve whitespace
16:49:56 <Steven> sorry, dropped the phone, just a moment
16:50:09 <oedipus> GJR: BLOCKCODE versus PRE
16:50:11 <Steven> zakim, dial steven-617
16:50:11 <Zakim> ok, Steven; the call is being made
16:50:13 <Zakim> +Steven
16:51:33 <oedipus> GJR: PRE literally as-is
16:51:52 <oedipus> GJR: BLOCKCODE can signal to assistive tech to respect and count whitespace
16:52:19 <oedipus> SM: BLOCKCODE doesn't preserve whitespace - layout attribute is irrelevant
16:52:48 <oedipus> GJR: point simply that whitespace is extremely hard to communicate to a non-visual user
16:53:19 <oedipus> GJR: python examples should be in BLOCKQUODE rather than PRE
16:53:38 <oedipus> s/BLOCKQUODE/BLOCKCODE
16:53:45 <oedipus> SM: made note to change example
16:54:04 <oedipus> SM: don't want to loose this thread 
16:54:14 <oedipus> GJR: will try and explain more clearly
16:54:35 <oedipus> ACTION: Gregory - send post to list explaining concerns over PRE
16:54:35 <trackbot> Created ACTION-70 - - send post to list explaining concerns over PRE [on Gregory Rosmaita - due 2009-04-02].
16:55:24 <oedipus> RM: HTML5 backtracked on Q to HTML2
16:55:38 <oedipus> SM: comment "why should be done in text and not stylesheet"
16:55:47 <oedipus>
16:56:16 <oedipus> GJR: "BLOCKQUOTE is nothing more than a presentational model taken from print conventions, rather than semantic meaning. If Q was ubiquitously implemented, one could use styling rules to create a Q instance with the properties of a block quotation -- that is, as a paragraph indented at least 5em on both left and right margins;"
16:56:33 <oedipus> GJR: favors a SINGLE quote element
16:56:44 <Zakim> -Roland
16:56:59 <oedipus> GJR: BLOCKQUOTE has no semantic meaning -- it is merely one means of many of demarcating any quote an arbitrary number of sentences long.
16:56:59 <oedipus> GJR: a quote is a quote is a quote - how it is demarcated as a quote is a presentational matter; what is important is that the material be logically and consistently marked up, so why have 2 forms of QUOTE, when only one is needed? 
16:57:14 <oedipus> SM: next comment - why an A element - answer: backwards compatibility
16:57:23 <oedipus> SM: why can't one use more than one CAPTION in a list?
16:57:33 <oedipus> SP: CAPTION for entire list, not part of it
16:57:37 <oedipus> 26634
16:57:54 <Zakim> +Roland
16:58:23 <oedipus> GJR: so are we in effect setting up a cascade that says CAPTION for whole item, LEGEND for components?
16:58:50 <oedipus> SM: don't have LEGEND element anymore
16:59:10 <oedipus> GJR: i've been working within PF to reuse the LEGEND element in HTML5
16:59:44 <ShaneM> (confirmed - we no longer have a legend element in XHTML 2)
16:59:55 <oedipus> GJR: since XForms carries LABEL, and LEGEND is no longer needed for the FIELDSET model that LEGEND  be reused as an organizational grouping desceriptor
17:00:26 <oedipus> RM: labelling a different discussion
17:01:16 <Steven> zakim, status?
17:01:16 <Zakim> I don't understand your question, Steven.
17:01:24 <oedipus> some thoughts on LEGEND:
17:01:29 <Steven> zakim, ports?
17:01:29 <Zakim> I see 92 ports in service, 76 ports idle
17:01:48 <oedipus> SM: 10 more items in AVK's list
17:01:56 <oedipus>
17:02:31 <Zakim> -Steven
17:02:32 <oedipus> RM: next address 13.1
17:02:32 <Zakim> -ShaneM
17:02:33 <Zakim> -Markus
17:02:34 <Zakim> -Roland
17:02:39 <oedipus> rrsagent, make minutes
17:02:39 <RRSAgent> I have made the request to generate oedipus
17:02:42 <Zakim> -Gregory_Rosmaita
17:02:44 <Steven> thanks Gregory!~
17:02:45 <Zakim> -Alessio
17:02:46 <Zakim> Team_(xhtml)13:00Z has ended
17:02:47 <Zakim> Attendees were Roland, Gregory_Rosmaita, +, Markus, Steven, Alessio, ShaneM, Tina
17:02:50 <oedipus> my pleasure
17:02:55 <oedipus> rrsagent, make minutes
17:02:55 <RRSAgent> I have made the request to generate oedipus
17:02:59 <oedipus> rrsagent, stop
17:03:53 <oedipus> present- [+]
17:03:59 <oedipus> rrsagent, make minutes
17:03:59 <RRSAgent> I have made the request to generate oedipus
17:04:18 <oedipus> present- +
17:04:22 <oedipus> rrsagent, make minutes
17:04:22 <RRSAgent> I have made the request to generate oedipus
17:04:49 <oedipus> rrsagent, stop
17:05:17 <oedipus> ==== ADJOURNED ====
17:05:25 <oedipus> rrsagent, make minutes
17:05:25 <RRSAgent> I have made the request to generate oedipus
17:05:28 <oedipus> rrsagent, stop
17:09:34 <oedipus> zakim, please part
17:09:34 <Zakim> Zakim has left #xhtml
17:09:39 <oedipus> rrsagent, stop