See also: IRC log
Previous minutes: http://www.w3.org/2008/04/09-xhtml-minutes
RM: progress on CSS Namespaces in CSS coordination group -- lin k to wording in post
<Roland> http://lists.w3.org/Archives/Public/www-style/2008Apr/0037.html
RM: asked to put words in, have been proposed within group, explaination of what happening in CSS; had problem with wording, i said words looked ok to me, but need to get WG ok
Steven: +1
GJR: no problem with adding note - +1
SP: if want standard selectors to work same, but still want to use CSS Namespaces, should use CSS selectors -- could add or stand pat
RM: good usage documents outside of spec - think we got what we asked for
ACTION - Steven: inform CSS CG that XHTML2 WG happy with note
<scribe> ACTION: Steven - inform CSS CG that XHTML2 WG happy with proposed paragraph [recorded in http://www.w3.org/2008/04/16-xhtml-minutes.html#action01]
XML Base (Second Edition)
http://www.w3.org/TR/2008/PER-xmlbase-20080320/
SP: not finished
XML Base (Second Edition)
http://www.w3.org/TR/2008/PER-xmlbase-20080320/
<scribe> ACTION: Steven - create questionnaire for June 2008 F2F [recorded in http://www.w3.org/2008/04/16-xhtml-minutes.html#action02]
SP: media-type discussion agenda item request
RM: ok
RM: TAG review, Steven preparing reply
... pointer to note:
<markbirbeck> CURRIEs is a much hotter topic. ;)
SP: only after general points will use Shane's extended verbiage -- that will be separate email
<Roland> http://lists.w3.org/Archives/Public/public-xhtml2/2008Apr/0050.html
http://lists.w3.org/Archives/Public/public-xhtml2/2008Apr/0050.html
SP: 1) TAG said "what precisely is requirement" -- surprised -- Introduction explains that; QNames can't address all URIs, so that's where the need for CURIEs enters
RM: if that is the case, can make more prominent in Introduction
SP: make intro more crisp?
RM: make clearer and more obvious in Intro
MB: been talking with Shane about rewrites of several sections to enhance clarity
SP: will reply to that effect -- crispen intro
to make primary req CURIEs intended to address
... 2nd point: overlap between CURIEs and QNames - could argue (as i am) that
that is a good point, and not a bad point; good for 3 reasonss: 1) specs that
use QNames where should be using CURIEs will be able to change datatype,
while old content still valued and new content extended; 2) syntax used and
easily understood; 3) syntax used in other places as well, so strange to
invent a new syntax
... not sure whether asking us to add to specification -- would not be open
to that (explaining background in spec)
RM: could look at some discussion/observation mentioning comparissons between QNames and CURIEs so not left to reader to interpret
MB: consequence of CURIEs will be that documents will still be valid and extensible
SP: regrettable that there is a clash between QName and CURIEs -- people used to using QName in host of languages; CURIEs only in syntaxic space -- not intended to be sent over wire; that is one of their worries -- CURIEs sent over the wire for processing, as opposed to a URI
MB: at top of comments state some comments based on earlier draft -- some of issues raised had been fixed by the time the draft they ostensively were reviewing
SP: should add "please note that the example to which you refer has already been excised"; don't think we should pussyfoot about this; ok to use CURIEs where URI allowed - represent same document space -- having to expand a pain and author burden; if but safe CURIE in a HREF user going to get a 404; think XHTML WG did right thing -- forward looking
MB: TAG should be clear when referring to CURIEs and when to CURIEs in RDFa -- syntax that removes ambiguity; haven't demanded that CURIEs be used everywhere URIs used; in RDFa don't allow CURIEs in HREF;
SP: make that a prominent point up front
... TAG argue against safe CURIEs -- "consider carefully the use cases" are
they really compelling? response: that's why they are in there - had
compelling use cases
... example in comment wrong; all you can use is a valid URI
... don't follow last point's reasoning - people can write the wrong thing;
already endemic
<markbirbeck> If xxx mapped to:
<markbirbeck> http://www.example.com/feeds/thursday/
<markbirbeck> there would be no problem.
MB: our area of concern is not the URI;
SP: only invalid if try to deference and points to xml document
MB: not invalid URI, just doesn't have effect you want;
SP: entirely up to author to use URIs legally
MB: about=#37b - wouldn't use id=
<markbirbeck> @@about="#37b"
RM: compelling use cases -- are they documented
in RDFa Use Cases? perhaps should be
... went through trouble of RDFa Use Cases might as well use it and use
language from it
... would be in primer -- people need to make use of it
SP: think can deduce from RDFa Use Cases that we need them; doesn't explicitly state it
MB: deduced from use cases documented in RDFa Use Cases -- if want to read, then they can
SP: ok
RM: apart from refinements just dicussed anyone against steven sending this as response?
SP: more thought about response, more i convinced myself what we are doing is absolutely right
[no objections logged]
SP: make changes and recirculate before list before sending to TAG
SP: since last we spoke, had 2 one and a half
hour meetings internally in w3c about this topic
... summarize: our position seems to be getting stronger; TBL seemed to lean
our way; think we are winning; some problems about shane's new mediatypes doc
-- had to repeatedly point out that an in-process draft; complaint that
XHTML2 should not define what HTML can do -- only drawing info from specific
specs and documentation of what is being done and what one can do
RM: was intended as a note anyway
SP: right; have to make sure that understood
that this isn't a spec or new reqs, but that a documentation of what
exists
... had to defend Appendix C -- at least 1 person upset that XHTML 1.0 can be
sent as text/html as long as follow appendix C - section that refers to
Appendix C is normative, but Appendix C is informative -- could cause
confusion was the complaint -- suggested that that suggestion be submitted to
list; like idea of issuing new edition of XHTML 1.0 -- good way to clarify
misconceptions and firmly stake our ground
... believe that TBL going to address this at either the AC meeting or the
conference in Beijing next week
RM: reason started this work was to help people writing XHTML and want to make sure will be rendered appropriately that don't know anything about application/xml -- just attempting to make clear what one should do if sending as text/html rather than application/xml
SP: been stated that "no one uses XHTML"
because being sent by text/html
... TBL surprised to hear no one used XHTML; more than 50% of top 20 web
sites using XHTML
MB: whole argument that datatype being delivered determines a language is a load; SHOULD pretty strong
SP: if create, run through validator but
deliver to IE as text/html, not author's intent
... assumed that UAs would switch on to new mediatype
MB: hope we learned our lesson
SP: why not use text/html -- upcry from XML community -- worried that that would "dirty" XML; HTML functionality turning up in XML; IE uses class solely to drive stylesheets, reason why didn't want us to use text/html; long discussions in IETF on this
MB: more general point - 2 worlds of XML; 1 where can have any document interpreted by schema; but in realworld actually very little ambiguities; pure XML world has a lot of baggage as does HTML world;
SP: difficult to spot in advance these types of issues; had no clue would be so difficult to get new media type into a browser
<markbirbeck> Tina...XML parsers are used to generate the XHTML, don't necessarily need to be used to consume it.
RM: 1) want to create XML with knowledge that may be served as XHTML or HTML; 2) what do we need to do - don't need to change our specs - already say SHOULD
SP: current plan to republish media note best can do for time being
RM: ok
GJR: plus 1 to SP
SP: think this is a battle that we are winning; TBL talking about how to get people to move towards well-formed content; in harmony with our underlying principles
<Tina> markbirbeck: then it might be best to transform the XML content to HTML before sending it to the client, to keep things simple.
RM: M12n request
SP: steveB travelling to beijing -- haven't had a reply yet
<markbirbeck> Tina: How is adding an extra step simpler than not adding an extra step? :)
SP: just re-checked email - no sent transition request 1 april 2008
RM: same with XHTML Basic?
SP: yes
<Tina> markbirbeck: quite easy. Today developers are sending entirely broken XHTML to clients, as text/html, thinking they use "well-formed XML". If we want 'well-formed content' on the clients, we either need to state clearly that XHTML *MUST* be sent with the proper media type, or accept that the work has to be done on the server.
SP: SteveB convinced there is connection btw
M12n and Basic; i and chris lilley have been trying to disabuse him of
that
... will also ping chris lilley to see if he has heard anything more?
RM: sitting around for a while; said would go to last call -- issues?
GJR: posted 2 issues on Access
http://lists.w3.org/Archives/Public/public-xhtml2/2008Apr/0044.html
http://lists.w3.org/Archives/Public/public-xhtml2/2008Apr/0045.html
<markbirbeck> Tina: Really? Are you seeing lots of broken mark-up?
<markbirbeck> (Broken XML, I mean.)
<Tina> markbirbeck: I see a huge amount of xhtml-doctype-sent-as-html which wouldn't pass muster as HTML 3.2, much less XHTML.
<markbirbeck> Tina: But you still have to ask...so what? We don't gain anything by insisting that they send the data as application/xhtml+xml, and then have browser reject it. What's the point of that?
<Tina> markbirbeck: do we gain any terrain for well-formed XML - on the client - by allowing XHTML to be sent with a content-type which does nothing to enforce those well-formedness rules?
GJR: only must activate be boolean? issue needs vetting, will address at both PF today and UA meeting thursday; don't forsee a major hold up
<Steven> I see no reason why text/html shouldn't be able to require wellformedness if the content is clearly XHTML
<markbirbeck> Tina: I don't really understand that point. Browsers have traditionally been pieces of software that allow people to read interesting things, buy music, book holidays, etc...why should they also be tasked with promoting and popularising XML by acting like a policeman or censor? (I.e., preventing people from interacting with any document that doesn't pass some test.) That's not the way the web has worked 'till now.
<markbirbeck> Tina: There are other tools to aid validation, the browser is really not a good one, especially when it's being used by an end-user; what does 'this is invalid XML' mean to them?
<Tina> markbirbeck: nothing much. But if the point is to "move towards well-formed content", then allowing a *stricter* - theoretically - language to be sent as, to put it bluntly, crap doesn't really help much.
<markbirbeck> Tina: I don't see "move towards well-formed content" as a goal in and of itself, though. It seems like a bad goal if it achieves "can't view this web-site".
<Tina> markbirbeck: nor do I, but it would appear that /is/ considered an important goal.
<markbirbeck> Tina: By whom?
<Tina> markbirbeck: TBL, it would appear.
<markbirbeck> Tina: I'm not sure you are right, there. :)
<Tina> markbirbeck: just quoting.