See also: IRC log
<Steven> Scribe: Steven
<oedipus> ScribeNick: oedipus
Yam: wait for more participants for mobile profile 1.3 and xhtml basic 1.1 PR - stable, can now make tests
<Steven> Agenda: http://lists.w3.org/Archives/Public/public-xhtml2/2008Jul/0000
<Steven> Meeting: XHTML2 Weekly Teleconference
Yam: OMA liaisoning finished, but my mission is mobile browsing, so i cannot continue to physically participate so i am saying goodby to group but if have any questions about mobile or testing, just ping me
<Steven> Previous: http://www.w3.org/2008/06/25-xhtml-minutes
SP: thank you Yam for all your valuable contributions
Yam: any issues on mobile browsing, will be more than happy to help
SM: thank you yam
RM: Shane & Tina were going to explore
SM: running battle in TAG about it
SP: background?
<yamx> Just drop mail to "Toshihiko.Yamakami@access-company.com" for any i12n or mobile browser issues.
<Steven> ok
thanks yam -- you will be missed
SM: some in TAG adamant that policies stated in doc are good idea, others who don't - impossible to reengineer all tech to support passwrods in clear; weird thing is they are ignoring SSL which is most widely used security layer - my comment what is wrong with SSL?
TH: didn't see anything more than last time i looked prior to f2f; no comments on it - good idea, but is it practical?
SM: not much in there - basically "make sure don't send passwords in clear and if you do, fix it"
RM: request to group to review - next steps? shane propose response from group on list
TH: the document won't be read by those except by those already involved in issue; don't understand why XHTML review needed? of course, shouldn't send passwords in clear
RM: 2 ways of rendering password
TH: both still need to be translated
SP: when you fill in things like a password in an HTML/XHTML form, what you type in is stored somewhere, so are passwords subject to attack via javascript
SM: sure
TH: possibly - no check of what's on disk
SM: once typed in, stored in DOM
SP: so susceptible to javascript attack and is in clear
SM: not encryption, just a specially rendered field - will check DOM spec
RM: question of DOM should say if such a DOM feature exists, use that
SP: XForms has same problem; input control has property that says "password" and nothing else - field is subject to javascript attack
TH: document in question talks about transmission - hacking way into DOM via javascript - thin connection - don't know if any point in commenting on it other than "this looks good in theory, but ..."
SP: if both HTML and XHTML store passwords where can be attacked by JS, can grab passwords
TH: what do with passwords after grabs them?
could use XML HTTPRequest object to send somewhere, but not to separate
host
... could add note that when comes to transmission of passwords in clear, it
doesn't affect us directly, but would like to poinot out the following DOM
concerns and parts of DOM spec (if contained there)
RM: OSes do not hold passwords in clear
SP: right
RM: encrypted as one-way encryption
SP: DVD player did store passwords in clear and allowed hackers to hack into DVD security layer
SM: will address by posting to list
RM: can you do this for us - volunteered to review new Schema draft by last call
questionnaire: http://lists.w3.org/Archives/Public/public-xhtml2/2008Jun/0058.html
SP: sent transition request
... question about role - issue together?
RM: Role not ready
SP: can't do together
RM: will address role shortly
... rather not hold up CURIEs
SP: good news with CURIEs is loads of
implementation already
... already have implementation reports for RDFa which include a lot of tests
for CURIEs
... may be a quick CR
RM: bits that changed as result of f2f -- short names to be fixed by Shane and IanJ
SM: half-way -- can't do anything to next pub anyway
SM: have draft - sent out note; no response
... done the proof-of-concept heavy lifting; oxygen doesn't choke on it, may
not be Relax Best Practice - trying to get Norm Walsh and another individual
as well as Chris Lilley to review
... ChrisL the one who asked the question; think can release as PER after 1.1
out the door
SP: know too little about RelaxNG
GJR: that makes 2 of us
SM: RelaxNG nor Schema not as powerful; we will have to define something perhaps, given the right URI here is the right Schema
SP: says "module not found" in a number of places
SM: thanks for reminder will grok right know
RM: when will make transition - any idea?
SP: searches for messages
RM: just a pulse check
RM: proposed 1.2, have to get 1.1 SE out door
TH: question: XHTML Basic 1.1 changed - some debate on mailing list - ignoring that or address it?
RM: complaint from mobile, why i asked yam about spec - mobile profile may define input mode not in Basic; XHTML Mobile Profile + Basic needed
SM: think TH talking about deprecating @style
RM: 2 issues: start of thread addressed being able to enter data, then moves on to deprecation issue
TH: setting input fields in node debate?
RM: yes
TH: do we need to address before move forward
RM: problem with XHTML Mobile rather than Basic
<Steven> Voting on Basic 1.1 is open until July 15th
SM: disagree
RM: one in past to set nodes - never in XHTML Basic 1.0 - through XHTML Mobile Profile addition
SM: and we added input mode to address shortcoming in Basic
RM: have to ensure that we have covered all of the input modes in Mobile
SM: didn't consider list extensible
RM: perhaps we can take up Yam on his offer to answer questions on mobile
SM: think should ignore - no LC or other comments nor follow up
RM: 2 statements: 1) input mode; 2) no
@style
... need to understand answers to input mode - is answer/feature we want in
Mobile profile
SP: WAP background and mindset
RM: @style in WAP different, but don't know
what OMA now says about Mobile profile - did they support new input modes not
found in Basic?
... need to address - could be a future flash point
... used WAP features in mobile work - very powerful
SM: next steps?
RM: i will write Yam and ask him what has
happened in this area with new Mobile profile; question comes from someone
dealing with XHTML Mobile Profile 1.2 or 1.3; not sure where question lies
... been working in Mobile space for some time - question is XHTML Basic 1.1
to corresponding mobile profile is what need to ascertain
... also concerned about @style deprecation - interesting discussion -
touched on it during F2F; no binding conclusion, but support for nested
STYLE
SP: use of @style for putting restrictions on input is bending spec to breaking point from W3C POV
RM: don't think restricted himself to saying @style useful only for that purpose
SP: but is a misuse of @style
RM: we can think of no compelling use of
@style, but if look at his use cases, might understand issue better
... no answer because we followed up in discussions on XHTML2
TH: use cases advanced so far is complaint about quality of managers, not spec
RM: component for mashup without getting into
style in HEAD
... @style been solution to that; adding to HEAD very difficult; nested STYLE
better
TH: taking 1 piece from point a and one from point b and putting together - where collisions happen; cascade of CSS - local style may collide with global style; assembling pieces should be done with content, not style
RM: still need to talk @style versus nestable STYLE outside of HEAD
TH: "real world" query - can't satisfy that
RM: no resolution because still under discussion
TH: might take his comments and simply tell discussion on table
SP: say that in spec
<Steven> We already say it in the spec
RM: haven't published latest version of XHTML2
- when have schedule for new draft and then query
... for use cases for solutions
SM: already replied to say "topic on table" he replied he was happy, so think we are done with this
RM: question of INPUT mode still open
... will look into input mode and talk with Yam about it
<Steven> Question of style attribute I think
SP: voting until 15 july 2008 - be sure to encourage people to vote
http://lists.w3.org/Archives/Public/public-xhtml2/2008Jun/0058.html
SP: be here next week, then away for 3 weeks
http://www.w3.org/2008/06/19-xhtml-minutes.html
<Steven> ACTION: Steven to write strawman on XHTML2/HTML5 wording [recorded in http://www.w3.org/2008/07/02-xhtml-minutes.html#action01]
RM: need to think through all ramifications of
resolution on @style logged in:
... where is Role
GJR: did AlG ever reply to ShaneM's post to pf on Role
SM: updated after last teleconference in
june
... transition document in w3.org space
RM: additional comments?
SM: checked and changed
RM: are we truly there - all comments that we have agreed solutions to?
SM: believe all submitters replied to and made all changes agreed to at f2f
RM: take look at latest draft
SM: Tina please check "badness" of bad examples
TH: i will
<Steven> ACTION: Roland to remind IBM AC rep to vote for http://www.w3.org/2002/09/wbs/33280/xhtmlbasic2008/ [recorded in http://www.w3.org/2008/07/02-xhtml-minutes.html#action02]
SM: typed URI into log of meeting as updated in
realtime
... dependent upon CURIEs anyway
... question to PF is ARIA talks about role, but not cited as an extension of
role
RM: overlap check between ARIA and Role
SM: yes - ripped out roles (in response to
document) - normative in #vocab
... ARIA people in charge of it, have to trust when say no conflict
GJR: believes roles not repetitive and no overlap
SP: actions coming out of discussion?
RM: Role is ready for us to review and resolve to move to CR
SP: vote on CR next week?
RM: yes
RM: comments?
GJR: doug replied to request of SVG as individual
<Steven> http://lists.w3.org/Archives/Public/www-html-editor/2008AprJun/0052.html
GJR: summarizes Acess discussion at PF face2face
RM: asked XForms?
SP: go official reply
<Steven> d/go/no/
<Steven> yet
PF face2face discussion of Access and HTML5/extensibility:
http://www.w3.org/2008/06/26-pf-minutes.html#item07
GJR notes that PF has formally asked for support for Access module in HTML5 or at least ability to use through extensibility
SM: ok to leave Ruby references in XHTML 1.1 as normative def?
SP: ok with it
SM: good with i18n
... considering recommending for compatibility HTML Mime
... with regard to i18n - recommend that documents be in UTF-8 or UTF-16 if
want them to be portable - take pulse on that?
SP: think will be delighted
RM: received feedback - might be worth asking if comments received by Forms WG
SP: by timing you mean?
RM: when bindings get done
SP: did ask last week with some discussion
<Steven> http://lists.w3.org/Archives/Public/public-forms/2008Jun/0067.html
<Steven> http://www.w3.org/2008/06/25-forms-minutes.html#item06
<Steven> http://www.w3.org/2008/06/25-forms-minutes.html#item06
SP: nick has action item to respond to XHTML2
WG on events
... john boyer has action item to comment on Access
GJR: got Access inserted into UAAG 2.0 under direct user control (previously only accesskey)
SP: Shane and i have been testing XHTML11+RDFa Modularized Schema on w3c schema validator - some issues to be ironed out but making progress
This is scribe.perl Revision: 1.133 of Date: 2008/01/18 18:48:51 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/RM/SP/ Succeeded: s/last minute/last teleconference in june/ Succeeded: s/all in harmony/roles not repetitive/ Succeeded: s/item03/item06/ Found Scribe: Steven Inferring ScribeNick: Steven Found ScribeNick: oedipus ScribeNicks: oedipus, Steven Default Present: Roland, ShaneM, Tina, Steven, yamx, Gregory_Rosmaita Present: Roland ShaneM Tina Steven yamx Gregory_Rosmaita Regrets: MarkB Alessio Agenda: http://lists.w3.org/Archives/Public/public-xhtml2/2008Jul/0000.html Got date from IRC log name: 02 Jul 2008 Guessing minutes URL: http://www.w3.org/2008/07/02-xhtml-minutes.html People with action items: roland steven WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]