12:39:50 <RRSAgent> RRSAgent has joined #xhtml
12:39:50 <RRSAgent> logging to http://www.w3.org/2009/03/10-xhtml-irc
12:39:55 <Steven> zakim, help
12:39:55 <Zakim> Please refer to http://www.w3.org/2001/12/zakim-irc-bot for more detailed help.
12:39:57 <Zakim> Some of the commands I know are:
12:39:58 <Zakim>  xxx is yyy       - establish yyy as the name of unknown party xxx
12:40:00 <Zakim>                     if yyy is 'me' or 'I', your nick is substituted
12:40:02 <Zakim>  xxx may be yyy   - establish yyy as possibly the name of unknown party xxx
12:40:05 <Zakim>  I am xxx         - establish your nick as the name of unknown party xxx
12:40:07 <Zakim>  xxx holds yyy [, zzz ...] - establish xxx as a group name and yyy, etc. as participants within that group
12:40:10 <Zakim>  xxx also holds yyy - add yyy to the list of participants in group xxx
12:40:13 <Zakim>  who's here?      - lists the participants on the phone
12:40:16 <Zakim>  who's muted?     - lists the participants who are muted
12:40:19 <Zakim>  mute xxx         - mutes party xxx (like pressing 61#)
12:40:21 <Zakim>  unmute xxx       - reverses the effect of "mute" and of 61#
12:40:23 <Zakim>  is xxx here?     - reports whether a party named like xxx is present
12:40:26 <Zakim>  list conferences - reports the active conferences
12:40:27 <Zakim>  this is xxx      - associates this channel with conference xxx
12:40:28 <Zakim>  excuse us        - disconnects from the irc channel
12:40:29 <Zakim> I last learned something new on $Date: 2009/03/10 16:59:31 $
12:42:23 <ShaneM> ShaneM has joined #xhtml
12:42:32 <Steven> can do
12:42:55 <Steven> :-)
12:43:45 <ShaneM> User Interface Rule #1: never anthropomorphize your software
12:44:13 <Steven> hwo many do we think are attending?
12:44:32 <oedipus> markus, shane, steven, gregory, roland
12:44:43 <oedipus> those that are here - will be here
12:44:52 <oedipus> didn't catch any regrets
12:45:00 <Steven> tina, mark
12:45:22 <oedipus> ah, i had hoped mark could be here, especially on the topic of forms in XHTML2
12:45:41 <Steven> alessio
12:45:43 <oedipus> markus is grabbing a bite to eat and a cup of coffee
12:45:54 <Steven> So that's 8 possibles
12:46:10 <oedipus> how many is the zakim reservation for?
12:46:23 <Steven> Gregory, watch this
12:46:59 <Steven> zakim, room for 8 people at 13:00Z for 240 minutes?
12:47:00 <oedipus> User Interface Rule #2: if you do antrhomorphize your software, don't be surprised when it de-humanizes you
12:47:02 <Zakim> sorry, Steven; could not schedule an adhoc conference; passcode overlap; if you do not have a fixed code you may try again
12:47:18 <Steven> woh
12:47:26 <Steven> 04 01zakim, room for 8 people at 13:00Z for 240 minutes?
12:47:40 <oedipus> zakim was REALLY flakey yesterday
12:47:46 <oedipus> even for Zakim
12:47:47 <Steven> zakim, room for 8 people at 13:00Z for 240 minutes?
12:47:50 <Zakim> ok, Steven; conference Team_(xhtml)13:00Z scheduled with code 26632 (CONF2) at 13:00Z for 240 minutes until 1700Z; however, please note that capacity is now overbooked
12:48:18 <Steven> Note code is CONF2
12:48:34 <oedipus> i can't tell the difference between the last rejected command, and the one zakim acknowledged ;-)
12:49:27 <Steven> nor can I, nor can I
12:49:34 <oedipus> ROTFL
12:49:41 <oedipus> Agenda: http://www.w3.org/MarkUp/xhtml2/wiki/2009-03-10-FtF-Agenda
12:52:49 <Steven> zakim, how many ports are reserved at 13:00?
12:52:49 <Zakim> on Tue Mar 10 13:00:00 2009 I see 58 reserved [34 available], 58 ports 30 minutes later [34 available], and 21 ports 60 minutes later [71 available]
12:53:28 <Steven> zakim, how many ports are reserved at 15:00?
12:53:28 <Zakim> on Tue Mar 10 15:00:00 2009 I see 36 reserved [56 available], 31 ports 30 minutes later [61 available], and 6 ports 60 minutes later [86 available]
12:53:45 <Steven> zakim, how many ports are reserved at 17:00?
12:53:45 <Zakim> on Tue Mar 10 17:00:00 2009 I see 0 reserved [92 available], 0 ports 30 minutes later [92 available], and 0 ports 60 minutes later [92 available]
12:53:59 <Steven> Doesn't look overbooked to me....
12:54:05 <ShaneM> low tech crap
12:54:08 <Steven> LOL
12:54:22 <Steven> I *really* must get that button made for you Shane
12:55:39 <oedipus> zakim may be showing the first glimmerings of AI - my older brother is an AI researcher whom i've always told "you'll know when you have a thinking machine when you command it to do something and it replies with a string of 4 letter words telling to programmer to "do it himself"
12:55:59 <Roland> Roland has joined #xhtml
12:58:47 <Steven> another 2 mins
12:58:57 <ShaneM> again - low tech crap
12:59:03 <Steven> booked at the hour
12:59:40 <Steven> shane jetlagged???
12:59:50 <Steven> This can't be the real Shane
12:59:53 <Steven> An imposter!
13:00:04 <Steven> zakim, dial steven-617
13:00:05 <Zakim> ok, Steven; the call is being made
13:00:06 <Zakim> Team_(xhtml)13:00Z has now started
13:00:06 <ShaneM> this is what happens when i dont travel for ages.
13:00:08 <Zakim> +Steven
13:00:59 <Steven> rrsagent, make log public
13:01:10 <Zakim> +??P12
13:01:13 <Steven> Meeting: XHTML2 WG Virtual FtF
13:01:22 <Steven> Chair: Roland
13:01:32 <Steven> rrsagent, make minutes
13:01:32 <RRSAgent> I have made the request to generate http://www.w3.org/2009/03/10-xhtml-minutes.html Steven
13:02:03 <Zakim> +Gregory_Rosmaita
13:03:39 <Steven> code CONF2 Roalnd
13:03:44 <Steven> Roland
13:04:32 <Zakim> +Roland_Merrick
13:04:46 <Zakim> + +04670602aaaa
13:04:57 <Roland> Zakim, Roland_Merrick is Roland
13:04:57 <Zakim> +Roland; got it
13:05:12 <Markus> Zakim, +04670602aaaa is Markus
13:05:12 <Zakim> +Markus; got it
13:05:20 <oedipus> http://lists.w3.org/Archives/Public/public-xhtml2/2009Mar/0072.html
13:05:30 <oedipus> http://xml.gov
13:05:54 <oedipus> http://xml.house.gov
13:06:58 <oedipus> zakim, who is here?
13:06:58 <Zakim> On the phone I see Steven, ??P12, Gregory_Rosmaita, Roland, Markus
13:06:59 <Zakim> On IRC I see Roland, ShaneM, RRSAgent, Zakim, Steven, oedipus, Markus, trackbot
13:07:17 <oedipus> http://xml.gov/cop.asp
13:07:25 <oedipus> http://xml.gov/standards.asp
13:07:45 <oedipus> http://xml.gov/efforts.asp
13:08:19 <Steven> http://xml.house.gov.
13:10:00 <oedipus> http://www.section508.gov
13:10:31 <Steven> Scribe: Steven
13:10:37 <Steven> Topic: Start
13:10:53 <Steven> Steven: Great news about Vivek as CIO
13:11:01 <oedipus> GJR: amen
13:11:07 <Steven> [discussion of Gov websites, XML, and use of]
13:11:48 <oedipus> second: Modules, Modularization, and the XHTML Family
13:12:23 <Steven> Topic: which version of XForms, 1.1? What about XML Events mismatch?  
13:12:23 <Steven>  XHTML2+XForms attribute clashes
13:12:25 <oedipus> zakim, allow speakers 30|00
13:12:25 <Zakim> I don't understand 'allow speakers 30|00', oedipus
13:12:32 <oedipus> zakim, allow queue 30|00
13:12:32 <Zakim> I don't understand 'allow queue 30|00', oedipus
13:12:50 <oedipus> http://www.w3.org/2001/12/zakim-irc-bot.html
13:13:12 <Steven> zakim, allow 30 minutes
13:13:12 <Zakim> ok, Steven
13:14:01 <oedipus> SP: have to say 1.1 because fixes so many things in XForms 1.0
13:14:07 <oedipus> SP: 1.1 in CR at moment
13:14:57 <oedipus> SP: we need to get the test suite through to implementations; EMC turned up with a test report on use of XForms; Chiva and Orbion are fighting to be number 2; ubiquity is coming on strong
13:15:11 <oedipus> SP: looking good for 2 test suites for XForms 1.1 completion
13:15:15 <Steven> Roland: s/Chiva/Chiba/
13:15:26 <Steven> s/Orbion/Orbeon/
13:15:30 <oedipus> SP: confident 1.1 will be out of last call by time XHTML2 goes to LC
13:15:37 <oedipus> RM: what about XML Events 2?
13:16:01 <oedipus> SP: xml events 2 taken things over from XForms 1.1 - borrowed good ideas - should be in events really
13:16:19 <oedipus> SP: not sure too much of a clash between 1.1 and 1.2
13:16:30 <oedipus> SP: xml events overlap is small
13:16:36 <oedipus> RM: something we should understand
13:17:07 <oedipus> ACTION: Steven - investigate overlap between XML Events 2 and XForms 1.1
13:17:07 <trackbot> Created ACTION-53 - - investigate overlap between XML Events 2 and XForms 1.1 [on Steven Pemberton - due 2009-03-17].
13:17:47 <oedipus> SM: Events 2 now modularized; handler module can flip directly with the builtin handlers in XForms 1.1
13:17:57 <oedipus> SP: doesn't handler module add action
13:18:16 <oedipus> SM: improved it (in air quotes) - don't think consistent or backwards compatible
13:18:22 <oedipus> SP: improvements
13:18:35 <oedipus> SM: MarkB's wish list; actions can use script
13:18:46 <oedipus> http://www.w3.org/MarkUp/Drafts/#xml-events2
13:19:03 <oedipus> SM: third module - SCRIPT (XML Scripting Module)
13:19:15 <oedipus> http://www.w3.org/MarkUp/2008/ED-xml-events-20081223
13:19:21 <oedipus> SP: will investigate
13:19:36 <oedipus> SP: changes in Events 2 - conditional actions taken straight from XForms 1.1
13:19:50 <oedipus> SP: some changes in XML Events 2 that are part of XForms 1.0
13:20:00 <oedipus> SM: targetid in 1.1
13:20:18 <Steven> ack shane
13:20:20 <oedipus> GJR: only reason for 1.2 was attempt to harmonize forms between XHTML2 and HTML5
13:20:38 <oedipus> SM: conflicts between XForms 1.1
13:20:41 <oedipus> MG: submission
13:20:50 <oedipus> SM: submission element
13:20:56 <oedipus> SP: received email on that
13:21:06 <oedipus> MC: paste list into chat (or URI)
13:21:11 <oedipus> rrsagent, make minutes
13:21:11 <RRSAgent> I have made the request to generate http://www.w3.org/2009/03/10-xhtml-minutes.html oedipus
13:21:19 <Roland> http://lists.w3.org/Archives/Public/public-xhtml2/2009Mar/0050.html
13:21:28 <oedipus> i/SP: have to say/ScribeNick: oedipus
13:21:33 <oedipus> rrsagent, make minutes
13:21:33 <RRSAgent> I have made the request to generate http://www.w3.org/2009/03/10-xhtml-minutes.html oedipus
13:21:43 <oedipus> SP: coding less of problem; target is a pain
13:22:00 <oedipus> SM: not convinced target is a pain - take them one at a time
13:22:11 <Steven> s/coding/encoding/
13:22:18 <oedipus> GJR: target ok if strictly defined - otherwise people will use javascript hacks
13:23:24 <oedipus> MG: fear that have universal problem -- XForms is the first external grammar trying to incorporate; Common Attribute Collection growing exponentially; i would like to think about our Common Attribute Collection
13:23:44 <oedipus> MG: MathML and SVG invoked externally - today garuntee collisions; investigate generic solution
13:23:58 <oedipus> SM: in those cases, those grammars not in XHTML2 namespace, so doesn't matter
13:24:15 <oedipus> SM: if role in global attributes, do it using namespace modifiers/prefixes
13:24:41 <oedipus> SP: agreed at some point to make special exceptions with XForms; XHTML2 began with understanding that XForms an integral part of XHTML2
13:24:51 <oedipus> SP: offered to import into XHTML2 namespace
13:25:07 <oedipus> SP: rules for porting XHTML2 onto other elements is that MUST be prefixed
13:25:21 <oedipus> MG: that should be a SHOULD, not a MUSTG
13:25:26 <oedipus> s/MUSTG/MUST
13:25:53 <oedipus> SP: if import XHTML2 href should namespace qualify with xh2:
13:26:22 <oedipus> MG: RelaxNG point of view - if define attributes, doesn't inherit namespace of parent element -- only belongs to namespace if prefixed
13:27:11 <oedipus> SP: attributes are not in a namespace unless namespace qualified; don't have to look into namespace to find attribute, but can also add namespace attributes to elements
13:27:23 <oedipus> SM: not sure understand MG's question
13:27:56 <oedipus> MG: 2 things: first, if there is quirkiness in way make schemas so can be qualified and unqualified depending on context
13:29:06 <oedipus> MG: second: how XForms editing will appear for users; if swallow all of XForms element set with our common attributes, may be recipie for confusion by authors; strikes me as strange to have @target on every XForms element in XML namespace
13:29:29 <oedipus> RM: take Common and break into smaller chunks so people can take what is most appropriate for their attribute collection needs
13:29:48 <oedipus> MG: looking forward at incorporation of future modules; common collection very large
13:30:02 <oedipus> SM: done what RM suggested - attribute collections and common
13:30:17 <oedipus> SP: common doesn't start big, but grows in accordance with elements used
13:30:32 <oedipus> SP: thought every element had "common" on it
13:30:39 <oedipus> SM: not all have common and not all need it
13:31:03 <oedipus> MG: from XHTML2 PoV that is right, XHTML M12n different?
13:31:04 <oedipus> SM: no
13:31:22 <oedipus> RM: need to make this point crystal clear so as to avoid misunderstanding
13:31:47 <oedipus> SM: open to defining which of XHTML2 attribute collections are added to the common collection
13:32:14 <oedipus> MG: [reads from spec] -- no requirement on common; you are correct shane
13:32:22 <oedipus> SM: same thing M12n 1.0 says
13:32:58 <oedipus> MG: either change XHTML2 to export reduced number of attribute collections; or try to disambiguate all collections one-by-one
13:33:09 <oedipus> MG: user point of view, would counsel first suggestion
13:33:19 <oedipus> SM: what does "introduce a reduced set" mean?
13:33:28 <oedipus> s/SM: what/SP: what
13:33:50 <oedipus> SP: RDFa - by importing RDFa adds to common because every element can have @property or @about
13:34:10 <oedipus> SP: not using common as a catch-all -- predicated on what other tech one is integrating
13:34:25 <oedipus> SP: many modules add attributes that have general effect
13:34:54 <oedipus> SP: regretable that if introduce @href, it bring @target with it -- problem @target used in XML Events and XForms
13:35:12 <oedipus> SP: solution not to reduce attribute sets -- doesn't solve problem - just makes certain things impossible
13:35:15 <ShaneM> q+
13:35:26 <oedipus> RM: need alternatives, then
13:35:27 <oedipus> q?
13:35:33 <oedipus> ack sh
13:36:21 <oedipus> SM: 2 points: 1) @target comes along with @href (could split them); 2) disagree with premise that by including whatever modules one is using, one is including every other module in attributes
13:36:38 <oedipus> SP: bit of risk: 1 place have @target and another @target that does something different
13:36:43 <oedipus> SM: not disagreeing with that
13:37:08 <oedipus> SP: one @target for XML Events and @target on submission from XForms
13:37:19 <oedipus> SM: removed @target from XML Events 2
13:37:45 <oedipus> SM: @target a very minor issue; would have same name, but in VERY different contexts; don't see as source of confusion
13:37:50 <oedipus> GJR: let commentors decide
13:38:17 <oedipus> SM: @resource is bigger problem; RDFa attributes need to be available for XForms elements; how do we deal with that?  no proposal
13:38:58 <oedipus> SP: @resource in XForms i opposed; just a renaming of the @src attribute, which is still there; created child of sumbission, resource, and wanted both to have same name; 
13:39:05 <oedipus> SM: proposal?
13:39:27 <oedipus> SP: is possible to drop @resource in XForms and still retain functionality; 
13:39:33 <oedipus> SM: can XForms handle that?
13:40:10 <oedipus> SP: no content in world except for test suites that uses @resource -- everyone uses @src -- @resource added because "looked better" -- wanted to retain @src
13:40:32 <Markus> q+
13:40:35 <oedipus> SP: can ask XForms to drop @resource and reinstate @src
13:40:54 <ShaneM> ack Markus
13:41:22 <oedipus> MG: other way is go route of namespace-qualified attributes; would be good if have solution that will work universally; using namespace qualified in XHTML would garuntee that would work forever
13:41:56 <oedipus> SM: that's what we tell language designers to do -- use MathML or SVG with our attributes, and when do so MUST do so with namespace qualifiers
13:42:04 <oedipus> SM: the SHOULD should be a MUST
13:42:22 <oedipus> MG: from use perspective won't be great for authors, but satisfies engineering reqs
13:42:41 <oedipus> RM: for those creating dialects, avoid clashes so not to have to create new namespace
13:42:56 <oedipus> RM: namespaces not popular; WGs going out of the way to avoid them
13:43:06 <oedipus> SM: appreciate MG's proposal
13:43:33 <oedipus> SM: not sure we can achieve this politically; don't like rolling stuff into namespace 
13:43:44 <oedipus> SM: XForms will be part of XHTML5 namespace
13:44:15 <oedipus> SM: wrap up - @target discussed - my position is don't include @target in common or @href in Submission
13:44:29 <oedipus> SM: hypertext attribute collection is not relevant and should not include @target
13:44:56 <oedipus> SM: as SP pointed out, coding not an issue; in XForms call "string" in our document make data-type more explicit
13:45:28 <oedipus> MG: i agree, but a schema processor wouldn't
13:46:00 <oedipus> MG: ask XForms group to specify data-type in the case of encoding more specifically
13:46:04 <oedipus> SM: like that idea
13:46:06 <oedipus> GJR: plus 1
13:46:14 <oedipus> SP: sounds good - checking XForms 1.1
13:46:31 <oedipus> MG: on SUBMISSION element
13:47:04 <oedipus> http://www.w3.org/TR/xforms/#structure-model-submission
13:47:20 <oedipus> "This element represents declarative instructions on what to submit, and how. Details of submit processing are described at 11 Submit."
13:47:37 <oedipus> "Common Attributes: Common"
13:47:45 <Steven> encoding
13:47:45 <Steven> Optional attribute specifying an encoding for serialization. The default is "UTF-8".
13:48:25 <ShaneM> ACTION: Shane to write up concrete proposal for dealing with XHTML 2 vs. XForms 1.1 attributes on SUBMISSION element etc.
13:48:25 <trackbot> Created ACTION-54 - Write up concrete proposal for dealing with XHTML 2 vs. XForms 1.1 attributes on SUBMISSION element etc. [on Shane McCarron - due 2009-03-17].
13:48:52 <Steven> XHTML2 - encoding = Encodings  
13:48:52 <Steven> This attribute specifies the allowable encoding of the external resource referenced by the @src attribute. At its most general, it is a comma-separated list of encodings, such as "utf-8", "utf8, utf-16", or "utf-8, utf-16, *".
13:49:29 <Steven> zakim, remind me in 30 to stop
13:49:29 <Zakim> ok, Steven
13:49:45 <oedipus> Special Attributes for XForms 1.0 SUBMISSION bind, ref, action, method, version, indent. mediatype, encoding. omit-xml-declaration, standalone, cdata-section-elements, replace, instance, separator, includenamespaceprefixes
13:50:09 <oedipus> TOPIC: section, h, and architectural purity
13:50:18 <oedipus> http://lists.w3.org/Archives/Public/public-xhtml2/2007Dec/0000.html
13:50:37 <oedipus> MG: i asked to have on agenda, but referring to different post
13:50:46 <oedipus> SP: strongly support this
13:51:14 <oedipus> SP: long had support for this PoV bar one member - can now get rid of h1 to h6
13:51:31 <oedipus> SP: like approach of putting them in legacy as long as make clear are legacy
13:51:45 <oedipus> RM: single module/collection called "legacy"?
13:51:49 <oedipus> RM: need a definition
13:52:11 <oedipus> SM: don't have legacy module yet - anything legacy and groups should be in own modules
13:52:13 <ShaneM> ACTION: Shane to create a new h1-h6 module marked as legacy.
13:52:14 <trackbot> Created ACTION-55 - Create a new h1-h6 module marked as legacy. [on Shane McCarron - due 2009-03-17].
13:52:33 <oedipus> MG: what goes in there in place of h1 to h6
13:53:00 <oedipus> SM: @target is good example
13:53:16 <oedipus> GJR: as long as author suggests, user accepts or rejects
13:53:31 <oedipus> TOPIC:  @title, caption and label etc
13:53:35 <oedipus>  http://www.w3.org/2009/01/21-xhtml-minutes.html#item03
13:53:47 <oedipus> SM: don't remember this discussion
13:54:37 <oedipus> MG: recap - have caption module now - available in TABLE, OBJECT and LISTS (label element for lists gone) - question is, in terms of CAPTIONs are we really done there -- should it be made part of common element collection so anything can be CAPTIONed
13:54:55 <oedipus> MG: second question: what happens with @title - perhaps candidate for legacy module
13:55:42 <oedipus> http://www.w3.org/MarkUp/2009/ED-xhtml2-20090205/mod-core.html#adef_core_title
13:55:51 <oedipus> SM: understand @title causes internationalization problem
13:56:07 <oedipus> MG: can we make CAPTION full replacement for @title and kill @title
13:56:24 <oedipus> SM: CAPTION part of text content module?
13:56:37 <oedipus> GJR: CAPTION used as header in TABLE in HTML
13:56:52 <oedipus> MG: have on TABLE and LISTS, which is good
13:57:12 <oedipus> MG: if in text module, could have captions on ABBR etc.
13:57:27 <oedipus> SM: if replacing @title, needs to be allowed everywhere @title is currently allowed
13:57:40 <oedipus> SM: or, this could tie back into discussion of the for attribute
13:57:56 <oedipus> http://www.w3.org/MarkUp/xhtml2/wiki/ProposedElements/forAttribute
13:58:26 <oedipus> SP: will take up when discuss @for
13:58:52 <oedipus> MG: if replace @title needs to be everywhere - assuming that title useful everywhere - is that true
13:59:05 <oedipus> GJR: needed for abbreviated form markup
13:59:32 <oedipus> SM: allowing CAPTION everywhere to replace @title
14:00:06 <oedipus> RM: rule for CAPTION?
14:00:13 <oedipus> GJR: nested header in TABLE context
14:00:22 <oedipus> SP: CSS selectors for CAPTION
14:01:11 <oedipus> SP: @title used for hover in HTML4x
14:01:29 <oedipus> q+ to ask what is content model for CAPTION for ABBR?
14:01:38 <Steven> Values of the title attribute may be rendered by user agents in a variety of ways. For instance, visual browsers frequently display the title as a "tool tip" (a short message that appears when the pointing device pauses over an object). Audio user agents may speak the title information in a similar context. For example, setting the attribute on a link allows user agents (visual and non-visual) to tell users about the nature of the linked resource:
14:02:07 <oedipus> GJR: in audio context state-of-art is either speak @title or speak link text
14:02:45 <oedipus> SP: XForms has HINT element for hover events; title widely used for abbr
14:02:47 <oedipus> ack oe
14:03:25 <oedipus> SM: CAPTION part of text module, can be child of ABBR
14:03:29 <Zakim> oedipus, you wanted to ask what is content model for CAPTION for ABBR?
14:03:43 <oedipus> SP: i18n waanted CAPTION as well as @title so can markup @title values
14:05:16 <Steven> s/aa/a/
14:05:19 <oedipus> GJR: intention of CAPTION in table is to provide terse descriptor
14:05:30 <oedipus> GJR: what is a caption and what is a description
14:05:36 <Steven> They wanted a TITLE element as child of all elements to allow marked up versions of @title
14:06:34 <oedipus> ABBR title="foo"><TITLE><STYLE>rich text here</STYLE></TITLE>
14:07:01 <oedipus> ABBR TITLE STYLE to apply speech/audio CSS 
14:08:40 <oedipus> RM: alt and labelledby from ARIA
14:08:49 <oedipus> s/RM: alt/GJR: alt
14:09:18 <oedipus> GJR: question for ARIA 2.0 is can labelledby and describedby take an IDREF
14:10:45 <oedipus> RM: XForms: has LABEL (rendered user has to do nothing to understand), HINT (implied gesture by user), HELP (available on user demand)
14:11:02 <oedipus> http://esw.w3.org/topic/PF/XTech/HTML5/MediaSpecificElements
14:11:33 <oedipus> suggested model for HTML5:
14:11:33 <oedipus> <ELEMENT>
14:11:33 <oedipus> <LEGEND></LEGEND> - required (maps to HTML4's @alt)
14:11:33 <oedipus> <CAPTION></CAPTION> - required
14:11:33 <oedipus> <DESC></DESC> - required (maps to HTML4's @longdesc)
14:11:33 <oedipus> <HELP></HELP>
14:11:35 <oedipus> </ELEMENT>
14:11:58 <oedipus> RM: not clear on how to say CAPTION is alternative to @title -- behavior different
14:12:07 <oedipus> SM: correct
14:12:21 <oedipus> RM: content model for LABEL and HINT the same - rendering instructions different
14:12:44 <oedipus> MG: need to look both at CAPTION and TITLE element, not either or
14:12:46 <oedipus> GJR: yes
14:13:12 <oedipus> MG: for abbreviations, not @title or @caption, but expansion
14:13:33 <oedipus> http://www.w3.org/MarkUp/xhtml2/wiki/ProposedElements/Initialisms
14:13:45 <oedipus> MG: @title needs to get bug fixed
14:14:13 <oedipus> GJR: also exposition methods are many - show expansion on status line
14:15:25 <oedipus> SM: proposal somewhere for "full" so don't have to repeat expansions
14:16:09 <Steven> <abbr id="bbc" full="British Broadcasting Corporation">BBC</a>
14:16:20 <oedipus> MG: RelaxNG shows full attribute available on ABBR
14:16:24 <oedipus> GJR: thanks!!!!
14:16:33 <oedipus> f u l l
14:16:49 <Steven> http://www.w3.org/MarkUp/2009/ED-xhtml2-20090205/mod-text.html#sec_9.1.
14:16:58 <oedipus> http://www.w3.org/MarkUp/xhtml2/wiki/ProposedElements/Initialisms#POINT_3._Building_More_Robust_for.2Fid_Associations_for_Abbreviation_Elements
14:17:08 <Steven> <p>The <span id="w3c">World Wide Web Consortium</span> (<abbr full="#w3c">W3C</abbr>) 
14:17:08 <Steven>    develops interoperable technologies (specifications, guidelines, software, and tools) 
14:17:08 <Steven>    to lead the Web to its full potential. <abbr full="#w3c">W3C</abbr> is a forum for 
14:17:08 <Steven>    information, commerce, communication, and collective understanding.</p>
14:17:32 <oedipus> GJR: doesn't like use of SPAN and id
14:17:59 <oedipus> q?
14:18:29 <oedipus> GJR: in your example rather SPAN to provide the ID, what DFN
14:19:12 <oedipus> <dfn id="w3c">World Wide Web Consortium</dfn> (<abbr full="#w3c">W3C</abbr>)
14:19:25 <oedipus> s/what DFN/whata about DFN
14:19:30 <Zakim> Steven, you asked to be reminded at this time to stop
14:19:32 <oedipus> rrsagent, make minutes
14:19:32 <RRSAgent> I have made the request to generate http://www.w3.org/2009/03/10-xhtml-minutes.html oedipus
14:19:57 <oedipus> SM: CAPTION part of text content set?
14:20:09 <oedipus> RM: what is its role and how do we define how it is rendered?
14:20:36 <oedipus> SP: CAPTION a child of TABLE -- what else?  IMG?
14:21:01 <oedipus> MG: because anything can be image, leads logically to inclusion in common set
14:21:09 <oedipus> SP: yep
14:23:10 <oedipus> MG: no or yes on moving @title to legacy and introducing TITLE element
14:23:30 <oedipus> SP: not make legacy, but stating have option  to use on or the other
14:23:40 <oedipus> SP: @title and TITLE have same meaning
14:23:59 <oedipus> SP: HenryT suggested should be format for attributes that allow them to be children 
14:24:18 <oedipus> SP: for simple use, @title attribute ok, if want something richer, use TITLE
14:24:30 <oedipus> RM: deprecate @title in favor of TITLE?
14:24:40 <oedipus> s/RM: deprecate/GJR: deprecate
14:24:48 <oedipus> SP: if conflict, child wins
14:24:53 <Steven> Not deprecate, just allow both
14:25:07 <oedipus> SM: content of title element the tooltip for the entire enclosed element
14:25:10 <oedipus> RM: yes
14:25:34 <oedipus> SM: RDFa - @title has a property of "DC.title" - only for @title in HEAD or all elements?
14:25:52 <oedipus> SP: attribute and elements; actual reason for title is to provide a DC.title
14:26:04 <oedipus> SM: never captured that in spec - will add to section currently revising
14:26:37 <oedipus> steven, what about @title and @style deprecated in favor of TITLE and STYLE
14:27:06 <oedipus> SM: takes interpretation; need to explictly state what we mean
14:27:10 <oedipus> SP: agreed
14:27:35 <oedipus> SM: different TITLE element than one in draft
14:27:41 <oedipus> SP: not different in meaning
14:28:02 <oedipus> SM: sounds ok
14:28:28 <ShaneM> ACTION: Shane to update the title element so it is clear that it can also be used in the text content set and that its contents become the "tooltip" for the enclosing element.
14:28:28 <trackbot> Created ACTION-56 - Update the title element so it is clear that it can also be used in the text content set and that its contents become the \"tooltip\" for the enclosing element. [on Shane McCarron - due 2009-03-17].
14:28:49 <oedipus> GJR: "tooltip" makes me squirm uncomfortable
14:29:08 <oedipus> SM: have to carefully craft text; content of TITLE element becomes tool-tip for HEAD element
14:29:21 <oedipus> SP: if made visible, should have tool-tip
14:29:59 <oedipus> SM: when TITLE defined in head, applies to document as whole, when used inline, refers to what it encases
14:31:01 <oedipus> SP: since TITLE element says is shorthand for property="title", RDFa already has special rules for children of HEAD which apply to document as whole; shorthand for meta
14:31:14 <oedipus> RM: would be good to restate that explicitly
14:31:32 <oedipus> GJR: replace "tooltip" with "user notification"?
14:32:00 <oedipus> SM: text module defines text content stuff including TITLE element
14:32:20 <oedipus> MG: some elements have structure - lists and tables
14:32:42 <oedipus> MG: applies to TABLE, lists, OBJECT, what else?
14:33:14 <Steven> [take 10]
14:33:22 <oedipus> TEN MINUTE BREAK - RECONVENE AT QUARTER TO HOUR
14:33:25 <Zakim> -??P12
14:33:27 <Zakim> -Markus
14:33:28 <oedipus> rrsagent, make minutes
14:33:28 <RRSAgent> I have made the request to generate http://www.w3.org/2009/03/10-xhtml-minutes.html oedipus
14:33:33 <Zakim> -Gregory_Rosmaita
14:33:39 <oedipus> rrsagent, stop
14:46:32 <oedipus> Scribe+ Gregory_Rosmaita
14:46:49 <Zakim> +Gregory_Rosmaita
14:46:58 <oedipus> rrsagent, make minutes
14:46:58 <RRSAgent> I have made the request to generate http://www.w3.org/2009/03/10-xhtml-minutes.html oedipus
14:47:20 <Zakim> +Markus
14:47:20 <Zakim> +??P7
14:47:29 <ShaneM> zakim, ??p7 is ShaneM
14:47:29 <Zakim> +ShaneM; got it
14:47:35 <oedipus> zakim, who is here?
14:47:35 <Zakim> On the phone I see Steven, Roland, Gregory_Rosmaita, Markus, ShaneM
14:47:36 <Zakim> On IRC I see Roland, ShaneM, RRSAgent, Zakim, Steven, oedipus, Markus, trackbot
14:49:03 <oedipus> TOPIC: Agenda Shaping
14:49:17 <oedipus> RM: suggest moving on to "TOPIC: Title Element and meta properties"
14:49:49 <oedipus> RM: can determine if earlier decision impacts title
14:49:59 <oedipus> TOPIC: Title Element and meta properties
14:50:24 <oedipus> http://lists.w3.org/Archives/Public/public-xhtml2/2009Jan/0045.html
14:50:36 <oedipus> RM: related to earlier discussion on title
14:51:35 <oedipus> SM: reading the definition of TITLE element right now - wanted on agenda because didn't understand how tied together meta property of title ties to the TITLE element
14:51:42 <oedipus> SM: have very casual statement in spec
14:51:51 <ShaneM> http://www.w3.org/MarkUp/2009/ED-xhtml2-20090205/mod-document.html#edef_document_title
14:52:37 <oedipus> SM: only place addressed in spec, currently
14:52:44 <oedipus> SM: thought said that about other things
14:53:06 <oedipus> SM: removed most of meta-data stuff from XHTML2 because it is available via RDFa
14:53:48 <oedipus> http://www.w3.org/MarkUp/2009/ED-xhtml2-20090205/mod-metaAttributes.html#s_metaAttributesmodule
14:54:11 <oedipus> "This section is normative for purposes of defining the integration of the XHTML Metainformation Attributes Module into XHTML 2. The semantics of the XHTML Metainformation Attributes Module itself are normatively defined in [RDFASYNTAX]. The rules for extracting RDF from XHTML family markup languages are defined in [RDFASYNTAX]. For information on important differences between XHTML 2 and other XHTML family markup languages and how those may relate to RDFa, see
14:54:32 <oedipus> http://www.w3.org/MarkUp/xhtml2/wiki/ProposedElements/CITE_and_cite
14:54:47 <Steven> zakim, remind me in 25
14:54:48 <Zakim> ok, Steven
14:55:28 <oedipus> SP: if TITLE equivalent to meta-title, anything meta-title can do TITLE should be able to do
14:55:55 <oedipus> SM: disagree - UA not going to look for TITLE in head, name document, but then change title in window frame when encounters new TITLE
14:56:23 <oedipus> SP: if say TITLE is metadata about document and state that UA has to deal with metadata in uniform way, then we can treat them identically
14:56:43 <oedipus> RM: TITLE is required in HEAD
14:57:10 <oedipus> RM: RDF processor would have to disambiguate
14:57:48 <oedipus> SP: if metadata, should have 1 story about metadata  -- up to now, saying TITLE in HEAD is shorthand for property="DC.title" -- all metadata, should treat all metadata in same way
14:58:10 <oedipus> RM: as the TITLE element is currently defined is a moot point; don't need processor to look anywhere but HEAD
14:58:29 <oedipus> SM: Steven trying to divorce those issues, which may be a good thing
14:58:48 <Steven> I think they are orthogonal
14:59:01 <oedipus> SM: don't believe that we have anything in XHTML2 to date othere than following sentence that implies that UA has to understand anything about RDFa
14:59:55 <oedipus> SM: lots of properties that have interesting correspondences with existing elements
15:00:30 <oedipus> SM: more appropriate for us to put requirements on RDFa processors - that they extract semantics from markup; put reqs on UA that interpret properties as markup
15:00:44 <oedipus> SP: what do you mean by "interpret properties as markup"?
15:01:02 <oedipus> SP: RDFa generalized method to add meta-data -- want to integrate the 2
15:01:14 <oedipus> SM: should be integrated in regards metadata
15:01:37 <oedipus> SM: UA looks at elements for attributes and does things with them; what it does with them is metadata
15:02:44 <oedipus> SP: triples are simply a way of storing metadata; unified how metadata works in XHTML, underlying info the same no matter what format stored in; HTML browser takes part of metadata and puts in window title doesn't change fact that TITLE in HEAD is metadata
15:02:51 <oedipus> RM: UA has to hunt for RDFa
15:03:22 <oedipus> SP: why "hunting"?  TITLE element or META property="DC.title" -- both should be stored in same way
15:03:38 <oedipus> SM: UAs don't look at metainfo; for servers, archiving, etc.
15:03:57 <oedipus> SP: my UA supplies bar across the top that tells me all about the metadata and enables me to use them
15:04:23 <oedipus> SP: at top of XHTML2 draft, button to take me home, button to take to previous, etc. -- plucking out metadata from head and doing something with it
15:04:40 <oedipus> RM: not expected to understand arbitrary RDFa properties
15:04:54 <oedipus> SP: no, just doesn't matter origin of metadata, UA should respond in uniform way
15:05:00 <oedipus> SM: have a vocabulary for that
15:05:14 <oedipus> SP: in doc say TITLE element equivalent to title property for document
15:05:37 <oedipus> SM: challanging fact that say that in 1 sentence; think unreasonable requirement on UA
15:06:00 <oedipus> SP: not unreasonable - metadata is metadata; would be mistake to separate them -- how to differentiate?
15:06:06 <oedipus> SP: should be unified
15:06:49 <oedipus> SM: if going to say UAs interpret "well-known metadata in XML vocabulary" as document properties, RDFa processors must extract other metadata?
15:07:01 <Roland> http://www.w3.org/1999/xhtml/vocab/
15:07:14 <oedipus> RM: clarification question: we have metadata defined in vocab document, but not included in vocab
15:07:28 <oedipus> GJR: vocab needs to be updated with LC aria roles
15:07:38 <oedipus> SM: took out of vocab because RDFa handles that now
15:07:50 <oedipus> SM: forgot we had removed from the vocab document
15:08:13 <oedipus> s/but not included/but title not included/
15:08:46 <oedipus> SM: example in section 7.3 needs to change - no property "title"
15:09:26 <oedipus> SM: do have defined vocabulary collection; doesn't have to be a title term in it, but there are other terms; do these have corresponding attributes in XML
15:09:32 <oedipus> RM: have to define it;
15:09:34 <oedipus> q_
15:09:37 <oedipus> q+
15:10:03 <oedipus> SM: if turn whole thing around - there is this mapping, want unified method of metadata, RDFa processors need to extract as well
15:10:12 <Steven> ack o
15:10:12 <oedipus> ack oe
15:11:33 <oedipus> SM: unified view needs both sides of problem described?
15:11:36 <oedipus> SP: definitely
15:11:49 <oedipus> SP: RDFa is described for XHTML 1.1 + RDFa
15:12:13 <oedipus> q+ to say want to discuss bringing CITE and @cite into harmony
15:12:45 <oedipus> ack oe
15:12:45 <Zakim> oedipus, you wanted to say want to discuss bringing CITE and @cite into harmony
15:13:03 <oedipus> GJR: discussion of bringing CITE element in line with the @cite
15:13:08 <oedipus> http://www.w3.org/MarkUp/xhtml2/wiki/ProposedElements/CITE_and_cite
15:14:03 <oedipus> SP: CITE and @cite do need to be unified
15:14:14 <oedipus> SP: don't know why need @cite element
15:14:25 <Steven> s/@//
15:14:35 <oedipus> GJR: 2 scenarios - one is as a pointer to CITE element for that resource
15:14:53 <oedipus> GJR: the other is text string that contains human-parseable information
15:15:50 <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
15:16:09 <oedipus> SP: CITE element gives human readable text - provides attribute that says where citing from
15:16:25 <oedipus> SP: Q and BLOCKQUOTE use @cite as @src
15:16:38 <oedipus> SP: why need @cite attribute if CITE does same work
15:17:04 <oedipus> <section role="main">
15:17:04 <oedipus> <q for="fdr3i" 
15:17:04 <oedipus> href="http://www.hicom.net/~oedipus/exegesis/fdr-third-inaugural.html#fdr3ip36s1"
15:17:04 <oedipus> cite="Franklin Delano Roosevelt: Third Innaugural Address; January 20, 1941"
15:17:04 <oedipus> >In the face of great perils never before encountered, our strong 
15:17:05 <oedipus> purpose is to protect and to perpetuate the integrity of democracy.
15:17:07 <oedipus> </q>
15:17:09 <oedipus> <!-- ... -->
15:17:11 <oedipus> </section>
15:17:13 <oedipus> <section role="secondary">
15:17:15 <oedipus> <h id="biblio">Bibliography</h>
15:17:17 <oedipus>  <ol>
15:17:19 <oedipus>    <li role="contentinfo"><cite id="fdr3i" 
15:17:21 <oedipus>    src="http://www.fdrpapers.gov/fdr3i.html"
15:17:23 <oedipus>    >Roosevelt, Franklin Delano. Third Inaugural Address. Delivered 
15:17:25 <oedipus>    before a joint session of congress, January 20, 1941. (official 
15:17:27 <oedipus>    White House transcript)</li>
15:17:29 <oedipus>  </ol>
15:17:31 <oedipus> <!-- ... -->
15:17:33 <oedipus> </section>
15:18:17 <oedipus> "Since href and src are available globally, why retain the cite attribute in its current form? Why not seize the opportunity presented by XHTML2's charter to make cite the attribute equivalent of the CITE element -- a means of identifying human-parseable citations of a work by title, author and date, as illustrated in the following example, which contains a quote from FDR's Third Inaugural Address: "
15:18:36 <Steven> By the way, I said the opposite - we don't need CITE element, since @cite adds the necessary magic to any element
15:18:48 <oedipus> oops, sorry steven
15:19:46 <oedipus> GJR: i suggested tying CITE element to Q and BLOCKQUOTE, etc. by a for/id mechanism
15:19:48 <Zakim> Steven, you asked to be reminded at this time
15:20:08 <oedipus> http://www.w3.org/MarkUp/xhtml2/wiki/ProposedElements/forAttribute
15:20:22 <ShaneM> What does this mean in terms of document meta data?  In terms of the Role module?  In terms of assistive technologies?  <img src="some.jpg" property="role" about="#this" id="this" content="xv:banner" />
15:20:46 <Steven> s/role/xv:role/
15:21:44 <oedipus> SM: point is "if RDFa style annotation affects way UAs treat metadata globally, UA and AT have to know what RDFa applies to
15:22:06 <oedipus> TOPIC: proposal: reintroduce @for into the Core attribute collection
15:22:11 <oedipus> http://lists.w3.org/Archives/Public/public-xhtml2/2009Jan/0066.html
15:22:11 <oedipus> http://www.w3.org/MarkUp/xhtml2/wiki/ProposedElements/forAttribute
15:22:57 <Roland> http://lists.w3.org/Archives/Public/public-xhtml2/2009Jan/0076.html
15:23:00 <oedipus> TOPIC: metadata (slight return)
15:23:25 <oedipus> RM: don't think we finished discussion of http://lists.w3.org/Archives/Public/public-xhtml2/2009Jan/0076.html
15:24:31 <oedipus> "In XHTML 2 we have meta only taking "Common" as its attributes.  That 
15:24:32 <oedipus> means we are dropping name, scheme, and http-equiv.  I am pretty sure we 
15:24:32 <oedipus> dropped http-equiv on purpose, but I feel like name and scheme should 
15:24:32 <oedipus> still be there?"
15:25:12 <oedipus> SP: for http-equiv, said ought to be done differently --- http-equiv mixes a lot of things in one bucket (media type and encoding, just 2)
15:25:56 <oedipus> SP: @name i'm not sure upon; if attempting to be compatible with old XHTML, leave @name on META in same way left on A (anchor) for legacy content so works in both old and new UAs
15:26:22 <oedipus> SP: if don't care about legacy, would suggest drop @name and use meta properties
15:27:10 <oedipus> SP: can do META in body -- that's what RDFa is all about -- don't have scheme there, so why in HEAD because of BODY?
15:27:26 <oedipus> SM: raised issue because wanted to determine if wanted to be backwards compatible
15:27:37 <oedipus> SM: don't think @name or @scheme should be retained
15:27:41 <oedipus> GJR: plus 1 to SM
15:28:05 <oedipus> SM: larger issue: 
15:28:34 <oedipus> SM: what it means for document metadata - META element anywhere in document, related issue
15:28:39 <ShaneM> http://www.w3.org/MarkUp/2009/ED-xhtml2-20090205/mod-meta.html#s_metamodule
15:29:22 <oedipus> SM: currently if look at content model for meta and link, link permits active links, meta permits PCDATA (to support RDFa in early stages) -- overcome by events, could put in historical module
15:29:36 <oedipus> SP: functionality of supplying META in body is provided by other means
15:30:07 <oedipus> SM: rich content in META may break support for XHTML2 in current user agents; should not have rich content model for meta or link
15:30:11 <oedipus> SP: can live with that
15:30:35 <oedipus> RM: if  have alternative, let's stick with that -- keep as easy as possible
15:31:16 <oedipus> RESOLVED: remove @name or @scheme from XHTML2; investigate feasibility of historical module
15:32:22 <oedipus> SP: in terms of what META does now, defined using RDFa techniques, easy to assert -- span in xhtml; nothing extra needs to be done in body -- can have nested spans with properties; not functional but purely syntatic 
15:32:59 <oedipus> SP: doesn't add extra functionality, but does add consistency; removing fences is best; but don't feel strongly either way
15:33:03 <oedipus> q?
15:34:15 <oedipus> SP: channelling MarkBirbeck -- having a HEAD is an historical artifact; could just have TITLE in BODY; only reason HEAD there was to mark "stuff not presented to user" before CSS; nowadays, distinction between HEAD and BODY less relevant
15:35:01 <oedipus> SM: should we permit nested META elements
15:35:09 <oedipus> SM: i say "no" because not supported
15:35:17 <oedipus> SM: but do understand other side
15:35:34 <oedipus> RM: is nested META only way to achieve what looking for?
15:35:41 <oedipus> SM: in HEAD it is; in BODY can use RDFa
15:36:48 <oedipus> MG: in DAISY have group working on RDFa expression of library cataloging standards; want to express standards using RDFa; triples not enough to capture contents of RDF -- need to associate triples with a scheme; developers happy that META elements can be nested in XHTML2
15:37:09 <ShaneM> ACTION: Shane to revert the link and meta content models to their XHTML M12N 1.1 content model but permit nested meta elements in the head. Do not permit @name and @scheme on meta though - they are not needed.
15:37:09 <trackbot> Created ACTION-57 - Revert the link and meta content models to their XHTML M12N 1.1 content model but permit nested meta elements in the head. Do not permit @name and @scheme on meta though - they are not needed. [on Shane McCarron - due 2009-03-17].
15:37:11 <oedipus> SP: if a use case and request, then should do it; those who don't want to use it can ignore it, those who do want to use nested META can
15:37:18 <oedipus> SM: In XHTML 2 we have meta only taking "Common" as its attributes.  That 
15:37:18 <oedipus> means we are dropping name, scheme, and http-equiv.  I am pretty sure we 
15:37:18 <oedipus> dropped http-equiv on purpose, but I feel like name and scheme should 
15:37:18 <oedipus> still be there?
15:37:39 <oedipus> RM: can be satisfied by other approach?
15:37:55 <oedipus> SM: Markus, can you provide me with details on nested META use cases?
15:38:05 <oedipus> MG: will do
15:38:12 <oedipus> timer, stop
15:38:13 <Steven> ack me
15:38:22 <Steven> zakim, remind me in 30
15:38:22 <Zakim> ok, Steven
15:38:57 <oedipus> TOPIC: proposal: reintroduce @for into the Core attribute collection
15:38:59 <Roland> http://lists.w3.org/Archives/Public/public-xhtml2/2009Jan/0066.html
15:39:03 <oedipus> http://lists.w3.org/Archives/Public/public-xhtml2/2009Jan/0066.html
15:39:03 <oedipus> http://www.w3.org/MarkUp/xhtml2/wiki/ProposedElements/forAttribute
15:39:54 <oedipus> SP: one thing about @for that has been raised in past -- existing @for on LABEL i am a big opponent of, as is TV Raman, because it is a presentation kludge; don't know which label is attached to which control and have to link them explicitly using for/id
15:40:27 <oedipus> SP: in XHTML2, not possible for LABEL to be separated from control; presentation methodology where appears on screen, so don't need @for for that purpose
15:40:48 <oedipus> SP: however, i do like the use of for/id to link Q and CITE and other links
15:41:31 <oedipus> GJR: one of the request i fielded about INS and DEL is that there is no way of binding what is being deleted to what has been inserted and i suggested that for/id relationship could fill that need
15:41:51 <oedipus> <INS id="insert13">This is the new text</INS>
15:41:51 <oedipus>    <DEL for="insert11">This is the text to be deleted.</DEL>
15:42:15 <oedipus> s/for=insert11"
15:42:27 <oedipus> s/for="insert11"/for="insert13"
15:42:32 <oedipus> rrsagent, make minutes
15:42:32 <RRSAgent> I have made the request to generate http://www.w3.org/2009/03/10-xhtml-minutes.html oedipus
15:43:03 <oedipus> proposed:
15:43:04 <oedipus> 1. That the for/id mechanism, which is already broadly supported in user agents and assistive technologies, be reused and extended in XHTML2 to provide explicit bindings between labelling text and the object or objects that text labels;
15:43:08 <oedipus> 2. That the for/id mechanism serve as a means of re-using values for ABBR, D, DFN, Q and CITE;
15:43:14 <oedipus> 3. A for/id relationship should also be used to mark the text which has been inserted, contained in an INS, and that which it is intended to replace, contained in a DEL tag, as in the following example: 
15:44:18 <oedipus> GJR: value would be IDREF
15:44:51 <oedipus> GJR: comments?
15:44:59 <oedipus> http://www.w3.org/MarkUp/xhtml2/wiki/ProposedElements/forAttribute
15:45:34 <oedipus> SP: instead of "full" on ABBR use "for" on ABBR
15:45:47 <oedipus> <dfn full="expansion">
15:46:29 <oedipus> http://www.w3.org/MarkUp/xhtml2/wiki/ProposedElements/Initialisms
15:48:27 <oedipus> SP: appreciate idea, but if going to generalize @for, have to ensure there is a general meaning - what does a SPAN for="" -- should only be added to common if used in single way
15:48:51 <oedipus> RM: difficulties of common -- already very large
15:49:21 <oedipus> SP: if has general meaning should be in common - principle if attributes are generalizable, then more useful
15:49:40 <oedipus> GJR: @id globally for free,
15:50:18 <oedipus> GJR: @for - purpose to establish explicit bindings and a re-use mechanism
15:50:47 <oedipus> RM: limited set of elements?
15:51:10 <oedipus> RM: start with expansion and then consider if should be common element
15:51:17 <oedipus> RM: references to common definition
15:52:19 <oedipus> ACTION: Gregory - investigate use cases for genericizing @for to ascertain if should be added to common/core attributes
15:52:19 <trackbot> Created ACTION-58 - - investigate use cases for genericizing @for to ascertain if should be added to common/core attributes [on Gregory Rosmaita - due 2009-03-17].
15:52:59 <oedipus> ACTION: Gregory - is @for useful in specific cases (enumerate) or can it be used generally
15:52:59 <trackbot> Created ACTION-59 - - is @for useful in specific cases (enumerate) or can it be used generally [on Gregory Rosmaita - due 2009-03-17].
15:53:17 <oedipus> GJR: will provide concrete examples as per RM's suggestin
15:53:24 <oedipus> s/suggestin/suggestion
15:53:55 <oedipus> http://www.w3.org/MarkUp/xhtml2/wiki/ProposedElements/forAttribute
15:54:36 <Zakim> -Gregory_Rosmaita
15:55:51 <Zakim> +Gregory_Rosmaita
15:56:20 <Steven> TOPIC: INS and DEL
15:56:21 <oedipus> TOPIC: INS and DEL
15:56:42 <ShaneM> Trying to remember what we agreed...
15:56:52 <oedipus> http://www.w3.org/MarkUp/xhtml2/wiki/ProposedElements/ModificationMarkup
15:57:13 <oedipus> http://www.w3.org/MarkUp/xhtml2/wiki/ProposedElements/MOD
15:58:18 <Steven> ack me
15:58:24 <oedipus> SP: why elements over attributes
15:58:31 <Steven> zakim, remind me in 28
15:58:31 <Zakim> ok, Steven
15:58:35 <oedipus> GJR: to keep the attributes from being attached to SPAN
16:00:02 <oedipus> SM: should have to insert elements for elements sake -- shouldn't need INS or DEL to carry this information; one option is use of semanticless element by adding attributes to annotate a change, the other is to do it declaratively with elements
16:01:17 <ShaneM> Content models of historical INS and DEL are not supportable.  
16:01:42 <oedipus>     *  Roland's straw-man example: @diff, with values of add, chg, del 
16:02:10 <ShaneM> So it is possible to have them within the text module as a way of having elements with explicit semantics as opposed to inserting a "span"...
16:02:28 <oedipus> is d<DEL>i</DEL><INS>o</INS> legal?
16:02:45 <oedipus> is d<DEL>i</DEL><INS>o</INS>g legal?
16:02:58 <oedipus>    1.  a means of marking editorial changes;
16:02:58 <oedipus>    2. a means of classifying an editorial change;
16:02:58 <oedipus>    3. a means of conveying when and by whom the change was affected;
16:02:58 <oedipus>    4. a means of binding an insertion with a deletion 
16:03:17 <oedipus> Question 1: should the above-listed attributes be handled using RDFa, rather than element-specific attributes?
16:03:39 <oedipus> Question 2: "what should be the mechanism used to add context and history to an INS or DEL element by using @src to link directly to the text that has been modified? "
16:03:57 <ShaneM> WOW - wonder if these modification elements/attributes define document properties that need tied in meta data via RDFa?
16:04:17 <oedipus> ould MOD with @src be handled differently than @src on other elements? should @href be used instead? 
16:05:16 <oedipus> SM: don't understand how RDFa ties into this
16:05:29 <oedipus> GJR: just tasked to see if RDFa could satisfy use cases
16:05:40 <oedipus> RM: fact of insertion and deletion more than RDFa
16:06:23 <oedipus> GJR: RDFa is useful for marking who made the change - when was made
16:07:21 <oedipus> SM: can make a triple out of anything, but just because one can doesn't mean one should
16:07:49 <oedipus> SM: information interesting to those data-mining; implicit relationship between who, the when and the what of the change should be sloughed off on RDFa
16:08:07 <oedipus> SP: details of who made change is metadata, and if is metadata, then should be treated as metadata
16:08:17 <oedipus> SP: all metadata should be treated the same
16:08:22 <Zakim> Steven, you asked to be reminded at this time
16:08:51 <oedipus> SM: follow that to the logical end - every paragraph is metadata -- everything can be tagged metadata
16:09:19 <oedipus> SP: don't consider P metadata, but person who changed contents of P (data about data) is metadata
16:09:37 <oedipus> SM: can argue pretty cogently that everything is metadata
16:10:13 <oedipus> RM: this is data that has been inserted; this has been inserted; don't care who wrote or when or why?
16:10:30 <oedipus> GJR: right but that underlying should be able to provided to a user who wants to know it
16:11:21 <oedipus> 1.  a means of marking editorial changes;
16:11:29 <oedipus> 2. a means of classifying an editorial change;
16:11:37 <oedipus> 3. a means of conveying when and by whom the change was affected;
16:11:50 <oedipus> 4. a means of binding an insertion with a deletion  through for/id
16:13:19 <oedipus> RM: 1 and 2 tied together
16:13:21 <oedipus> GJR: yes
16:13:47 <oedipus> GJR: important new consideration is 4 - binding waht has been deleted to what has been instered when both are in the same document
16:14:57 <oedipus> RM: that is metadata -- have to INS something in several places in document -- all created by same purpose and on same page -- bunch of changes for particular purpose
16:15:19 <oedipus> GJR: one thing we discuss was INS and DEL as inline and MOD as the block element for marking change
16:15:36 <oedipus> s/we discuss/we discussed
16:17:07 <oedipus> SP: attributist - not big fan of reintroducing these elements; use of generic SPAN is frowned upon by some
16:17:56 <oedipus> SM: should i conclude you are in favor of including INS and DEL
16:17:58 <oedipus> GJR: yes
16:18:22 <oedipus> RM: can't get excited over issue - can live with attributes or elements, as long as elements are local in scope
16:18:49 <oedipus> RM: insert a section with an INS shouldn't be allowed
16:18:53 <oedipus> SM: agree
16:19:00 <oedipus> SM: how opposed are you, steven?
16:19:48 <oedipus> SP: not sure -- very much prefer attribute solution, but understand long history of element version;
16:20:15 <oedipus> SP: on the other hand, point of moving to XHTML2 is removing elements that mark up structures, but semantics
16:20:31 <oedipus> SP: part of semantics, not structure which is why i prefer attribute solution
16:20:48 <ShaneM> PROPOSAL: introduce the INS and DEL elements as "legacy" in their own module and only in the text content set.  
16:20:59 <oedipus> MG: could we put it in legacy module?
16:21:03 <oedipus> SP: could live with that
16:21:06 <oedipus> GJR: so could i
16:21:15 <oedipus> RM: sounds ok to me
16:21:28 <ShaneM> ACTION: Shane to develop a legacy INS and DEL module that adds those elements to the text content set.
16:21:28 <trackbot> Created ACTION-60 - Develop a legacy INS and DEL module that adds those elements to the text content set. [on Shane McCarron - due 2009-03-17].
16:21:53 <oedipus> RESOLVED: introduce the INS and DEL elements as "legacy" in their own module and only in the text content set
16:22:30 <Steven> ack me
16:22:38 <Steven> zakim, remind me in 30
16:22:38 <Zakim> ok, Steven
16:23:24 <oedipus> TOPIC: Action 14 - features document
16:23:39 <oedipus> http://lists.w3.org/Archives/Public/public-xhtml2/2009Jan/0044.html
16:24:16 <oedipus> SM: identify granular features and feature collections that can map to the @implement for Script Module
16:24:18 <oedipus> RM: yes
16:25:14 <oedipus> SM: architecture for document: use RDFa and the annotation conventions from the vocab document to identify these collections and their granular parts; parts and selections map essentially to modules in M12n 2.0
16:25:30 <oedipus> SM: question: do we intend to support @implements in M12n 1.0
16:25:35 <oedipus> SM: my answer is yes
16:25:39 <oedipus> SP: sooner the better
16:26:09 <oedipus> SM: features should map to M12n 2.0 - M12n 1 and M12n 2 don't overlap - do we need 2 features modules, one for each?
16:26:31 <oedipus> SM: don't think can have 2 versions of features, because need to move language forward
16:26:32 <Zakim> Steven, you asked to be reminded at this time
16:26:59 <oedipus> SM: if don't have 2 versions of features document, needs a well known URI (as with the vocab document) -- will need version names
16:27:50 <oedipus> SM: summary: features doc needs to represent current state-of-the art and a conversion/adaptation guidance; need to organize a heirarchy in RDF
16:28:08 <oedipus> SP: that's a lot to think about
16:28:16 <oedipus> SM: that's why the action is still outstanding!
16:28:52 <oedipus> SM: suggestion: can get movement on this by picking core features we care about having in attributes today and call it the features document and say will be added to
16:29:03 <oedipus> SP: couldn't it just be a CURIE?
16:29:21 <oedipus> RM: if feature is a URI, should define URI for each feature
16:29:39 <oedipus> SP: implements=xh1:foo
16:29:56 <oedipus> SP: implements=xh2:xforms
16:30:03 <oedipus> SM: URI or space CURIE
16:30:15 <ShaneM> s/space/safe/
16:30:17 <oedipus> SM: reserved words in single repository
16:30:43 <oedipus> SM: implement XForms 1.1 would then have meaning -- reserved word mapping available
16:31:17 <oedipus> SP: if do that, CURIEs allows one to say if prefixed use certain namespace
16:31:32 <oedipus> SM: "reserved words" can mean whatever we want - take out of context of CURIEs
16:31:48 <oedipus> SM: pre-fix-less CURIEs are problematic; can only have 1 default for each
16:32:11 <oedipus> SP: not going into vocab document, but if can't have key words as appropriate value of a URI
16:32:19 <oedipus> SM: #$@!%
16:32:40 <oedipus> SP: accept what RM suggested - not going to write very often; will be copied-and-pasted
16:32:56 <oedipus> SM: done all the time by developers -- bringing in scripts
16:33:01 <oedipus> RM: cut-and-paste
16:33:17 <oedipus> SP: like namespace or doctype - part of standard template
16:33:39 <oedipus> 30 MINUTE WARNING
16:33:55 <oedipus> SM: probably just use URIs for most part in examples to keep simple and clear
16:33:57 <oedipus> +
16:34:25 <oedipus> SM: features we need implements values for today: Access, Role, XHTML 1.2, client-side RDFa
16:34:56 <oedipus> SM: will put up skeletal document for review and hope someone is inspired to help me
16:35:02 <ShaneM> Note - NO RESERVED WORDS FOR @implements
16:35:16 <Steven> ack me
16:35:23 <Steven> zakim, remind me in 30
16:35:23 <Zakim> ok, Steven
16:35:36 <oedipus> TOPIC: Modules, Modularization, and the XHTML Family
16:35:43 <oedipus> http://lists.w3.org/Archives/Public/public-xhtml2/2009Feb/0019.html
16:36:38 <oedipus> MG: about M12n 1.0, right?
16:36:40 <oedipus> SM: true
16:36:54 <oedipus> MG: those are intertwined heavily - hard to seperate them
16:37:01 <oedipus> GJR: agrees with Markus
16:37:21 <oedipus> SM: tangental issue on how to do fragment announcements - would like to address seperately
16:37:48 <oedipus> SP: difference between language sub-setting and UA sub-setting
16:37:50 <oedipus> SM: yes
16:38:03 <oedipus> SP: should be allowable to sub-set languages, but not user agents
16:38:05 <oedipus> SM: yes
16:38:30 <oedipus> SM: UAs need to support everything through modules
16:39:15 <oedipus> SP: one reason introduced M12n was to try and pull the world into a decent standard set of languages; needed differences to be consistent and predictable
16:39:33 <oedipus> SP: m12n allows sub-setting and extension in defineable and controllable ways
16:39:57 <oedipus> SP: can sub-set language as much as you want provided UA accepts that sub-set as well as super-set
16:40:16 <oedipus> MG: provider of module can mark / designate module by pointing to it
16:40:19 <oedipus> SM: optional
16:40:21 <oedipus> MG: yes
16:40:41 <oedipus> SP: UA still accepts full language, but some versions of language are checkable in reduced version
16:40:56 <oedipus> SP: what is the "win"?  if all UAs have to accept whole module, who wins?
16:41:20 <oedipus> SM: language designers - XHTML family markup languages with restriction on content authors can create
16:41:29 <oedipus> SP: think i can live with that
16:41:53 <oedipus> SP: didn't distinguish between content sub-setting and UA sub-setting
16:42:00 <oedipus> SM: exactly; mea culpa
16:42:44 <oedipus> SP: while on the topic, reraise RM's complaint about not being able to declare taht content is XHTML Print and XHTML Base compliant
16:42:56 <oedipus> RM: would like to address at some point
16:43:15 <oedipus> RM: if written content specifically so will validate by XHTML 1.1 processor and XHTML Basic processor
16:43:28 <oedipus> RM: when put in declaration i want, mobile processor won't accept
16:43:44 <oedipus> RM: current limitation is have to declare 1
16:43:50 <oedipus> SM: real problem, agree
16:44:19 <oedipus> RM: recognize this happens and people want to do these things - out of one, many; how to write content for the entire web?
16:44:59 <oedipus> SM: doctype -- TBL doesn't like use of doctype anymore; but if using doctype, can't use more than one
16:45:34 <oedipus> SM: in theory, could define a set of rules for doctype public identifiers that would mean "this document is blah, blah, and blah" but not sure if that scales
16:45:51 <oedipus> SM: there is the @version attribute - currently only takes single value
16:46:00 <oedipus> MG: what about link rel="profile"
16:46:12 <oedipus> GJR: also thinking along @profile lines
16:46:29 <oedipus> SP: rel="version"
16:46:32 <oedipus> SM: interesting idea
16:46:42 <oedipus> MG: what meaning does @profile have then?
16:47:02 <oedipus> SP: rel="profile" used for profiles that define value of attributes rather than implying content model
16:47:16 <oedipus> SM: how UA should interpret values of rel, href and class in HTML
16:47:38 <oedipus> SM: could just add another reserved value for this case
16:48:23 <oedipus> MG: how planning/hoping to do in DAISY with grammars on top of XHTML2 with link rel="version" -- only thinking of having one, but possibility of multiples is tantalizing
16:48:41 <oedipus> SM: XML Schema's location attribute to declare multiple schemas
16:48:48 <oedipus> RM: is a hint -- we need to give locatoin
16:49:03 <oedipus> SM: @location can point to 5 different schemas
16:49:17 <oedipus> MG: solution should be general enough for use in processors
16:49:29 <oedipus> SM: don't want to rely on a hint
16:49:39 <oedipus> SM: like idea of using LINK
16:49:39 <Steven> +1
16:49:43 <oedipus> GJR: plus 1
16:50:00 <oedipus> SM: don't think any existing rel values map to case; need new one
16:50:18 <oedipus> MG: "version"
16:50:49 <oedipus> MG: href cannonical URI - processor can auto-discover resources associated with language
16:51:16 <oedipus> MG: capable of using RDFa vocabulary - what is at end of namespace URI for DAISY use would be grammar
16:51:32 <ShaneM> rel="version" href="canonical URI for version" - need to create good examples for these.
16:51:50 <oedipus> SM: not sure what canonical URIs for languages
16:51:54 <oedipus> SP: for us to decide
16:51:59 <Steven> the TR URI
16:52:24 <oedipus> SM: should be a fixed string a language processor can rely on
16:52:30 <Steven> zakim, remind me in 9 that it is 6 o'clock
16:52:30 <Zakim> ok, Steven
16:52:39 <Zakim> Steven, you asked to be reminded at this time
16:52:51 <oedipus> SM: what makes for a good identifier -- i.e. one not date-stamped
16:53:00 <oedipus> TEN MINUTE WARNING
16:53:06 <oedipus> SP: been a really good meeting
16:53:14 <oedipus> RM: got through several items
16:53:25 <oedipus> SM: like this format better than the 1 hour meetings -- get more done
16:53:34 <oedipus> TOPIC: Next Meetings
16:53:48 <oedipus> RM: will have regular call tomorrow (11 March 2009)
16:54:00 <oedipus> RM: schedule another virtual F2F before end of march
16:54:05 <oedipus> SP: dates?
16:54:52 <oedipus> ADJOURNED
16:55:18 <oedipus> rrsagent, make minutes
16:55:18 <RRSAgent> I have made the request to generate http://www.w3.org/2009/03/10-xhtml-minutes.html oedipus
16:55:29 <Zakim> -ShaneM
16:55:31 <Zakim> -Markus
16:55:31 <Zakim> -Roland
16:55:33 <Zakim> -Steven
16:55:40 <oedipus> RM: XHTML2 call on 11 March 2009 -- will discuss scheduling of next virtual face2face
16:55:44 <Zakim> -Gregory_Rosmaita
16:55:45 <Zakim> Team_(xhtml)13:00Z has ended
16:55:47 <Zakim> Attendees were Steven, Gregory_Rosmaita, Roland, Markus, ShaneM
16:55:47 <oedipus> zakim, please part
16:55:47 <Zakim> Zakim has left #xhtml
16:55:54 <oedipus> rrsagent, make minutes
16:55:54 <RRSAgent> I have made the request to generate http://www.w3.org/2009/03/10-xhtml-minutes.html oedipus
16:56:36 <oedipus> scribe: Gregory_Rosmaita
16:56:41 <oedipus> rrsagent, make minutes
16:56:41 <RRSAgent> I have made the request to generate http://www.w3.org/2009/03/10-xhtml-minutes.html oedipus
16:57:31 <oedipus> regrets: Tina, Mark, Alessio
16:57:32 <oedipus> rrsagent, make minutes
16:57:32 <RRSAgent> I have made the request to generate http://www.w3.org/2009/03/10-xhtml-minutes.html oedipus
16:57:36 <oedipus> rrsagent, stop