07:42:14 RRSAgent has joined #xhtml
07:42:14 logging to http://www.w3.org/2008/06/18-xhtml-irc
07:42:20 Zakim has joined #xhtml
07:42:27 zakim, this will be xhtml
07:42:27 ok, Steven_; I see IA_XHTML2()4:00AM scheduled to start in 18 minutes
07:42:38 rrsagent, make log public
07:43:13 Meeting: XHTML2 WG Virtual FtF, Day 2
07:43:16 Chair: Roland
07:43:50 Agenda: 04http://www.w3.org/MarkUp/xhtml2/wiki/2008-06-FtF-Agenda01
07:44:03 04rrsagent, make minutes
07:44:40 rrsagent, make minutes
07:44:40 I have made the request to generate http://www.w3.org/2008/06/18-xhtml-minutes.html Steven
07:48:18 mu irc UA copies colours with cut and paste, and they end up as escape sequences in the log which rrsagent doesn't recognise
07:48:23 s/mu/my/
07:49:03 drag... can you disable that?
07:51:20 Not as far as I know
07:52:14 no substitute for good old command line *nix irc
07:54:02 yep, I guess
07:58:10 emailed Access Module comment requests to UbiWeb, UAAG and SVG
07:59:03 IA_XHTML2()4:00AM has now started
07:59:10 +Roland
08:00:13 zakim, dial steven-617
08:00:13 ok, Steven; the call is being made
08:00:18 yamx has joined #xhtml
08:00:18 +Steven
08:00:46 +Gregory_Rosmaita
08:03:07 +??P2
08:03:39 zakim, ??P2 is yamx
08:03:39 +yamx; got it
08:04:24 It seems like the microphone with my handsets have some problems. I have to take the handset manually to release hand-free mode to speak...
08:09:43 omw
08:12:16 IFRAME Accessibility Inquiry: http://lists.w3.org/Archives/Public/wai-xtech/2008Jun/0061.html
08:14:02 +ShaneM
08:14:11 zakim, who is here?
08:14:11 On the phone I see Roland, Steven, Gregory_Rosmaita, yamx, ShaneM
08:14:12 On IRC I see yamx, Zakim, RRSAgent, oedipus, Roland, ShaneM, Lachy, Steven
08:14:58 poetic justice?
08:15:44 Scribe?
08:16:03 scribeNick: oedipus
08:16:17 RM: review of yesterday; new review of CURIE received today
08:16:40 TOPIC: CURIEs
08:17:31 http://lists.w3.org/Archives/Public/www-html-editor/2008AprJun/0048.html
08:17:39 RM: model response on that submitted on behalf of XForms?
08:17:43 http://lists.w3.org/Archives/Public/www-html-editor/2008AprJun/0049.html
08:18:22 RM: personal comment from leigh: "We will clear up the wording to help reduce any potential confusion. We
08:18:22 will also clarify that host languages are only required to use XMLNS for
08:18:22 prefix definition if the language supports XML Namespaces. Thanks!
08:18:22 "
08:19:29 SM: saw new comments last night; no DTD because the DTD is in M12n -
08:19:53 RM: we make it clear that there is a separate pointer to one or the other
08:20:15 RM: put pointer to say definitive definition is pointed to and provide pointer
08:20:36 RM: defined in one place - need to reference elsewhere
08:20:40 SM: ok
08:21:11 SM: comment continues - confused as to why normative - perhaps whole section should be informative
08:21:31 RM: normative schema can be found here and the normative DTD can be found here, but section not normative itself
08:21:46 SP: normative bit is syntax - DTDs and schemas just informative
08:21:50 RM: mixture in section
08:22:04 SP: either make DTD and schemas normative both or informative both
08:22:15 RM: normative reference in M12n
08:22:25 SM: and point to it from informative section
08:22:46 SM: in the m12n implementation, but is not in modularization itself
08:23:00 SM: didn't went m12n have dependency on CURIEs
08:23:37 SP: think good not to link to m12n - people should be able to use CURIEs regardless of implementation method
08:23:48 SP: DTD and schema informative is ok
08:23:56 SM: don't mind relaxNG thing
08:24:21 RM: more general point on what to do with RelaxNG for future - syntax for constraint, not type definitions
08:24:42 SP: Relax uses schema datatypes to find datatypes - used for program structure
08:25:03 RM: avoid RelaxNG now
08:25:21 SP: XHTML2 spec has RelxNG - future will include, but too late to add now
08:25:43 RM: informative definition of RelaxNG might enhance readability - very editorial, not real request for RelaxNG
08:26:03 SM: intend to do work on RelaxNG in future, but want to address in cohesive fashion in very near future
08:26:28 SM: should i redirect comment into tracking system so is logged as LC comment
08:26:32 RM & SP: yes
08:27:54 TOPIC: XHTML Mime Type
08:28:14 RM: draft available; email about new tool from olivier
08:28:26 http://www.w3.org/MarkUp/2008/ED-xhtmlmime-20080423/
08:28:38 SM: how to approach
08:28:44 RM: work our way through document
08:29:19 http://www.w3.org/MarkUp/xhtml2/wiki/2008-06-FtF-Agenda
08:29:21 http://www.w3.org/MarkUp/2008/ED-xhtmlmime-20080423/
08:30:40 SM: took old one, put in pub system; made least number of changes possible; added appendix and that's where things stand
08:30:53 SM: diff marked version from previous
08:30:53 http://www.w3.org/MarkUp/2008/ED-xhtmlmime-20080423/xhtmlmime-diff.html
08:31:01 SM: will help other people
08:31:13 SM: should approach as new document today
08:31:23 RM: start at introduction and work our way forwards
08:31:36 http://www.w3.org/MarkUp/2008/ED-xhtmlmime-20080423/#intro
08:32:47 SP: see part of our implementation strategy for XHTML2 going via script route; scripts that implement XHTML2 part and runs down tree making necessary changes so works within existing HTML browsers
08:33:04 SP: in that case, many UAs will have to receive as text/html just to serve, so...
08:33:23 SP: when we say "use of text/html should be limited to HTML-compatible..." -- wonder if that is too strong
08:34:22 SP: media type is being used to deliver stuff to UA just to get it in there, then - due to scripting - deliver XForms - UA thinks is HTML, and then script does what is necessary to compile into HTML
08:34:46 SP: want to deliver documents to UAs as text/html, but want to be very careful about definition of HTML-compatible
08:35:02 RM: distinction not between documents, but capacities of browser;
08:35:13 SM: browsers that explicitly accept that mime-type
08:35:41 RM: focus on document negotiating with browser and serving most appropropriate - if wants text/html, give it
08:36:00 RM: this is XML and that is what we are
08:36:10 SM: disconnect by the way Roland & Steven
08:36:40 RM: UA only meant to parse well formed XML, should deliver xml mime-type - you take XML, we have XML, here it is
08:37:02 SM: if FF claims to accept XML and XHTML, why serve text/html
08:37:17 SP: no if UA accepts application/xml give it that
08:37:33 SP: hiccup is use of text/html should be limited to HTML-compatible family documents
08:37:47 SM: right -- it does say that
08:37:49 the use of 'text/html' SHOULD be limited to HTML-compatible XHTML Family documents intended for delivery to user agents that do not explcitly accept 'application/xhtml+xml'.
08:37:51 "the use of 'text/html' SHOULD be limited to HTML-compatible XHTML Family documents"
08:38:17 SM: a SHOULD not a MUST
08:38:53 SM: thought intent was not to irritate constituencies using XHTML1 - transitional thing; has to be HTML-compatible, or target UA may not accept it
08:39:03 SP: depends on our definition of HTML-compatible
08:39:22 SM: try to explain in Appendix C of XHTML 1.0 - Appendix A of this document
08:39:46 RM: if UA asks for page and prefers XML, serve as XML; if UA doesn't support XML only HTML, then serve text/html
08:39:59 RM: document agnostic - can do either thing and respond based on what UA wants
08:40:16 RM: not document constraint per se, but browser constraint, which we handle
08:40:52 SP: explicitly mention cases where people doing stuff - implementing XML based languages via scripting; in that case, acceptable to deliver as text/html just to get to UA
08:41:09 RM: not sure right justification - doc should state what should be done, not justify
08:41:33 SP: don't want to get into current situation where people claim not XML because being delivered via text/html
08:41:40 SP: in past didn't care about media types
08:41:56 RM: this is where should be strong - not about media types, but whether passes series of constraints
08:42:11 RM: mandating particular doctypes wrong approach
08:42:22 SP: doctype only current way to declare restraints
08:42:38 RM: can make assertion against a document through validation -
08:43:07 RM: can write a doc where all markup valid against mobile profile, xhtml10 and xhtml11 - why have to pick one
08:43:14 Tina has joined #xhtml
08:43:35 SM: possible to craft doc that can validate against any of our markup family, but this WG has said "have to have doc type"
08:44:18 SP: if want to declare doc as mobile OK, document has to have basic DTD in front - if someone else declares as foo, need another DTD even if document satisfies both standards, can't validate as both
08:44:41 SP: rule about doctype to use constrains authors from authoring once and declaring valid for a number of profiles
08:44:44 RM: correct
08:45:02 SM: not clear how relevant to document or what we can do
08:45:44 RM: perfectly acceptable to deliver as XHTML1.0, XHTML1.1, Mobile Profile, HTML5 -- pipe stream can then use text/html or application/xml
08:45:58 RM: assertion part of document not metadata
08:46:46 RM: is byte stream acceptable as text/html in HTML4x browser; same byte stream delivered to valid mobile device, then deliver as application/xml; not implicit to byte stream
08:47:09 SM: media type tells the consumer how to evaluate document - what internal engine to use
08:47:20 RM: that's not intrinsic to document, but how bind 2 together
08:47:57 RM: can take same byte stream into FF and whether served as text/html or application/xml works
08:48:03 SM: side-effects: changes the DOM
08:48:15 SM: is there anything in doc that is in conflict with your points
08:48:51 RM: turn around question - how respond to request from UA, not something intrinsic in document - document can legitimately be multiple form (valid in more than one langauge)
08:49:07 SM: hope that that behavior is encouraged by this doc
08:49:31 RM: document-centric approach (what to push to browser) rather than responding to UA requests - push-pull or pull-push
08:49:49 RM: what UA asks for or is capable of understanding determines how we act
08:49:57 SM: first paragraph of abstract says that
08:50:19 alessio has joined #xhtml
08:50:46 RM: if browser asks for application/xml send as that - serve what UA prefers; negotiation in pike
08:51:26 RM: XML higher fidelity, but if only understands one or other, then that is the constraint, not the document
08:51:50 RM: response from negotiation with UA; this is what i can accept, give me the highest fidelity
08:52:13 TH: without a DOCTYPE many tools beome impossible to write, such as accessibility checkers
08:52:22 Without a DOCTYPE many tools becomes impossible to write such that they can deliver trustworthy results. Accessibility checkers is one such example.
08:52:30 +1 to Tina's comment
08:53:16 Yam: as mobile UA manufacturer, don't want to be bound to any mime-type - process what we can; interested in using mime-type to advertise browser capability; media type specification or note?
08:54:23 Wouldn't it be far more useful to continue the work on CC/PP instead of using the mime-type, since the mime-type, looked at pragmatically, doesn't really say anything about capability?
08:55:02 Yam: if note, emphasize 1.0 or 1.1 - from mobile UA viewpoint, this module will clarify how to handle XHTML Basic as well as other XHTML flavors; 2 editorial points: status of document (have to make sure consistent); second in 3.5 say HTML, should be HTML4 other places HTML-compatible; need to define HTML compatible or explicitly state HTML4-compatible
08:55:10 tina, yes to CC/PP
08:55:10 My comment was not that DOCTYPE should not be used but that a single document can conform to more than one DOCTYPE.
08:55:23 Yam: profile
08:55:36 SM: need strategy for that - came up on RDFa discussion this week
08:56:35 Yam: mimetype profile should require specification of DTD -- can clarify have to use profile + foo; my assumption is have to use profile parameter and in doing so have to specify DTD
08:57:21 SM: haven't developed concrete strategy there; markB has other ideas; had other suggestions; reasonable to use mimetype but need to do in rec track document or m12n, otherwise, not normative
08:57:30 Yam: happy with informative
08:58:07 SM: issue with HTML-compatible and HTML4 - HTML4-compatible would explicitly exclude HTML5 for better or worse
08:58:22 GJR +1 to HTML4-compatible
08:58:30 SP: too early to say HTML5
08:58:43 Yam: don't know anything about HTML5 compatibility
08:58:47 SM: absolutely right
08:58:57 SM: HTML4-compatible ok?
08:58:58 GJR: yes
08:59:03 Yam: yes
09:00:06 +??P8
09:00:10 RESOLVED: in mimetype document use HTML4-compatible and HTML4-foo wherever appears in document to remove confusion
09:00:23 zakim, ??P8 is Alessio
09:00:23 +Alessio; got it
09:00:23 zakim, ??P8 is Alessio
09:00:24 I already had ??P8 as Alessio, Steven
09:00:56 RM: what should abstract say that currently doesn't?
09:01:37 RM: how to make as easy as possible for authors to develop content so can be delivered in multiple mimetypes
09:02:01 SM: something about title?
09:02:26 RM: title itself doesn't get to heart of what trying to do - guide for authors on how to develop content so can be served as multiple media types
09:02:36 SM: understand, but title already well-know
09:03:07 RM: title - XML Media Type sub-title: Serving XML in an HTML World
09:03:19 SP: Serving XHTML in Legacy UAs?
09:03:28 RM: Serving XHTML to Multiple User Agents
09:04:14 Delivering XHTML to XHTML and HTML User Agents
09:04:16 Serving the Most Appropriate Content to Multiple User Agents from a Single Document Source
09:04:24 RM: who is expected to read?
09:04:29 SP: olivier
09:04:51 That was intended as a joke, for the record
09:05:08 SM: consumers of document: all people who hang out on freenode #web who say don't use XHTML because doesn't work
09:05:40 SM: if can get them to understand ok to serve XHTML to current UAs, then that is a huge win
09:06:37 Yam: reason document more implemented on mobile browser is no way to specify XHTML Basic or other/multiple host language support; W3C note will gratify my constituency
09:07:43 I find that hard to agree to. Most authors appear not to know how to use XHTML. It wouldn't do the "XHTML Case" any good to have an even larger amount of invalid documents out there that people believe are "just fine" 'cause they render as HTML.
09:07:56 RM: that's what we were trying to discuss earlier - what UA is capable or ready to accept - i accept A, B, C, D, and E so give me the best one you have
09:08:33 RM: capability of browser and then if document fits multiple profiles; basic 1 and basic 1.1 - UA conforms to basic 1.0, takes that
09:09:30 SM: logical conclusion means need to specify somewhere a syntax for the accept headers profile parameter -- markB has proposal; UA has to say in precise and concise way all of the things it accepts
09:10:00 SM: tokens specified for implements in XML Events 2 - could be that sort of mechanism
09:10:15 Yam: no other document specifies that
09:10:31 SM: agree - might push into update of RFC if part of media spec
09:10:48 RM: should consult with UbiWeb and CC/PP
09:10:51 +Tina
09:11:50 RM: break off as topic that needs attention - problem about UA advertising capabilities and preferences and serving the appropriate content
09:12:03 SM: markB should be in on discussion
09:13:11 SM: how to make abstract get to point RM wants reword "documents intended for delivery to user agents that do not explcitly accept 'application/xhtml+xml'. 'application/xml' and 'text/xml' MAY also be used, but whenever appropriate, 'application/xhtml+xml' or 'text/html' SHOULD be used rather than those generic XML media types."
09:13:42 RM: question of persepective - how to respond to UA's capabilities and preferences
09:13:45 XHTML Family documents intended for delivery to user agents that do not explcitly state in their HTTP-Accept header that they
09:13:45 accept 'application/xhtml+xml'
09:14:04 SM: that what you mean, Roland?
09:14:06 RM: yes
09:15:15 Tina: problem with it is that everyone knows that an accept head is often misleading - tend to ignore accept headers and HTTP requests; not a road we should formally go down - should not ignore accept
09:15:45 Tina: understand pragmatic reasons, but uneasy with exception for HTML-family document; should talk with HTTP people
09:15:54 SP: don't understand what you think we are ignoring
09:16:17 Tina: UAs use accept header that says "i'll accpet everything no matter what" - then how to decide what to give it?
09:17:07 SP: accept header should give list of what can actually accept, but with a terminal star to cache ("Save As.." dialog is an example - not refused, but check accept headers to check if can natively deal with it
09:17:38 SM: according to HTTP spec, permisible to accept *.* -- we're telling people to ignore that
09:18:04 Tina: formal point of view would mean we are telling people to ignore part of HTTP spec
09:18:12 SP: not saying that
09:18:16 SM: think we are, actually
09:18:53 SM: term "explicitly state" - unless UA explicitly says it accepts application/xhtml+xml don't give it xhtml - that's inconsistent with spirit of HTTP spec
09:20:02 SP: by saying *.* how do you get xhtml documents in to browsers and parse them correctly; all UAs accept *.*, which means "don't exclude anything"
09:20:20 RM: these are things UA might say - if this is X do Y, if this is Q do W
09:20:31 Tina: need to check on *.* support in UAs
09:20:57 Tina: usual way of writing accept header parsers haven't come across many that accept anything
09:21:20 Tina: need to investigate further - can we delay discussion so can dig into it a bit?
09:21:24 Here Tina: http://pgl.yoyo.org/http/browser-headers.php
09:21:30 Lachy has joined #xhtml
09:21:43 Opera sends: Accept: text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1
09:22:18 RM: peice that is missing; talk about things in abstract not covered in detail - detail goes into media type uses, but don't say what requests might come form UA; accept headers not mentioned in body, just in abstract
09:22:31 in our list of explicit rules.... how about if we say "if an Accept header only contains */*, documents SHOULD be sent using media type text/html if they are HTML4 compatible, or as application/xhtml+xml if they are not" or something.
09:22:40 Safari sends: Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
09:22:45 RM: in media type usage, should say "which is the most appropriate"
09:23:01 TH: worth noting that ones tested so far send a Qvalue with *.*
09:23:19 TH: who set up yoyo.org?
09:23:47 yoyo: "Welcome to Yoyo Internet Services. We pride ourselves on consistency of service and quality of workmanship. Founded in 1996 by Matt Saunders and Neil Levine, Yoyo has gone from strength to strength despite its overwhelming vacuousity."
09:23:51 Mozilla: Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
09:24:18 "Our mission is to consistently conjugate through dynamism, surrealism and semanticism in order to further our goals of hysterical servlet hypotenae. This autonomy cultivates our duplicitous mercenary valetism in the eclectic dot org arena."
09:24:21 Amaya:
09:24:21 Accept:
09:24:21
09:24:21 */*;q=0.1,image/svg+xml,application/mathml+xml,application/xhtml+xml
09:24:34 RM: accept header fallback for browser detect
09:24:38 Tina: not useable
09:24:42 GJR: easily forged
09:25:08 Tina: need to point out that should do that
09:25:23 Lets add a section for dealing with content negotiation via accept headers explicitly
09:25:24 RM: process accept headers to determine which of possible types to send - not addressed in detail
09:25:37 alessio has joined #xhtml
09:25:40 RM: give accept header and respond
09:26:45 Yam: OMA specifies that UA should advertise their supported mimetypes - send QValues because of *.* - at end smallest QValue
09:26:53 RM: please send us a pointer
09:26:59 Lynx sends: Accept: text/html, text/plain, application/x-bittorrent,
09:26:59 application/x-troff-man, message/partial, message/external-body,
09:26:59 application/x-tar, application/x-gtar, application/msword,
09:26:59 text/richtext, text/enriched, application/ms-tnef, text/*,
09:26:59 application/x-debian-package, audio/basic, */*;q=0.01
09:27:07 SM: i introduced that before OMA was OMA
09:27:26 My local Lynx sends text/html, text/plain, text/css, text/sgml, */*;q=0.01
09:28:03 s/ s/<\/nobr>//
09:28:24 i often change my lynx settings in response to browser sniffing so i can get into certain sites
09:28:30 SP: fifteen minute break?
09:28:42 === 15 MINUTE BREAK ===
09:28:49