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

Minneapolis Face2Face

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

CURIEs

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

Mime-Type

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.

Status of Documents

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?

Access Module

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.