See also: IRC log
SP: we asked for 3 things: drop it or deprecate
it or point it out in the spec that this is a change in CSS and this is how
you avoid problems;
... said will ignore comments -- replied to that: asked if refusing to merely
pointing out in spec ok
... accept disapproval or get an answer, but if no, have to document before
CR
... this has a 1 week heartbeat, so if they accept to point out in spc, we
are ok; need to deciide what to do if don't accept any part of our
comments?
... object or accept the fact they rejected our comments/suggestion
... don't think much to ask to ask them at the minimum to point out that this
is a change in CSS; if don't should say not sufficient, as it is a change in
CSS
RM: inclined to agree
SP: not much to ask -- don't have to change implementations -- is WG ok with us saying that the least we want them to do is point it out in spec?
RESOLUTION: CSS NS must at least point out that there is change in CSS
SP: waiting on Shane to make a new iteration of draft; he's done that, so i'm emailing steve bratt and going throough points and pointing to new spec and asking if ok with transition
RM: just going through process
<scribe> ACTION: StevenP - point SteveB to new wording in M12n [recorded in http://www.w3.org/2008/03/26-xhtml-minutes.html#action01]
SP: "would you have a look at the new/latest version of the report"
<Steven> http://www.w3.org/MarkUp/2008/xhtml-basic-11-implementation.html
SP: at bottom, there is a pointer to Yam's response and test report
[please stand by -- we are temporarily experiencing technical difficulties]
<Steven> http://www.w3.org/MarkUp/2008/a-w3c-inputmode-test-report071130.pdf
SP: need to correct test report with above
URI
... [fixed implementation report - can now get PDF report from draft]
MB: input mode?
SP: since rest has been implemented, only new item is input mode -- we had exchange with Steve Bratt to see if ok to have single implementation because is optional feature, and he said that was ok; have to organize another transition call with SteveB
RM: see if he's happy then schedule LC
SP: will take us to CR
<scribe> ACTION: SP to ensure SteveB ok with single implementation and get transition in progress [recorded in http://www.w3.org/2008/03/26-xhtml-minutes.html#action02]
SP: Karl seems to think anything not absolutely
valid and without application/xml mime-type is NOT xhtml -- that's only a
single person's opinion
... DanC agrees with us but doesn't see the problem
... will discuss at this week's HTC call -- request discussion now or simply
move ahead
RM: prepare materials to be published as part of the mime-types first draft; explain what we have done, what has changed, and what is purpose, can then bring up at HTC
SP: like fact that there are a lot of major web sites delivering xhtml as text/html -- proves can be done and that it works without doing any harm
RM: seen doctype "HTML Core" but use closing slashes -- real mixture both ways
SP: drop line to webmaster to change doctype
GJR: FYI: the "official" format of Open Accessibility (http://a11y.org) specs is XHTML 1.0 Strict
SP: Shane preparing new draft to take to HTC
RM: don't foresee any problem -- already allowed
RM: everything ready to go, but we don't have shane on call -- suggestions as to topics while we wait
SP: could briefly talk about TAG's opinion about mime-type when using RDFa
RM: pointer?
SP: comes under RDFa syntax; have action to let TAG know we disagree -- was drafting reply and realized we hadn't spoken with RDFa group, so i raised it at last week's meeting
<Steven> http://www.w3.org/2008/03/20-rdfa-minutes.html
<Steven> http://www.w3.org/2008/03/20-rdfa-minutes.html#item02
SP: self-describing web (item 2)
... BenA (chair of Task Force) asked if TAG wrong; Ralph abstained no one
else agreeed; RDFa group almost unanimously agree with us that media type
doesn't need to be updated to use RDFa data in HTML
RM: namespace?
SP: don't understand TAG point at all or what is foundation of belief -- hard to argue against updating media type
MB: TAG logic is that somebody should not be held accountable for statements made unless accountability indicator
SM: proposed wording towards end of last call
SP: norm walsh proposed wording or you (ShaneM) proposed wording
MB: NormW raised issues, ShaneM replied, and everything was ok -- Norm's was most vocal objection, and we have cleared it
SP: pointer?
SM: has an issue number in tracker (not at
PC)
... suggested wording something like "conforming parsers MUST extract triples
if present; authors who want to use triples should use proper methods" or
words to that effect
RM: where can we find the exchange
SM: in the RDFa task force log somewhere
SP: NormW's emails all about missing @profile in test case
SM: origin of issue; DanC asked why test cases didn't all have @profile and then others asked why isn't that required
SP: quotes from NormW -- (pointer?)
SM: interesting that NW thinks we are changing the meaning of HTML; so does TBL -- don't think we have done that at all
SP: me neither
GJR: nor me
SP: next steps?
... if this is all result of a LC comment which has been disposed and the
commentor has stated publically can live with WG's response, can we move
forward -- TAG document only a WD, so can wait until before LC to comment
upon that
... new doctype
SM: not new media type, but new doctype
RM: but have introduced new doctype for this
SP: want one to be able to ID documents that
have RDFa in it; then TBL says doctypes are obsolete and advises us to remove
DTD...
... but, having said that, have "version" attribute in XHTML -- is an
announcement mechanism, so should point that out to TAG
... have we finalized format of "version" attribute -- struck me that one
possible format is identify used in DOCTYPE --
SM: exactly what is in there now
... inconsistent with XHTML 1.0 and 1.1 and Basic
... use longer formal public identifier
... never investigated this
SP: issues about doctype -- doctype causes
current browsers use DTD to switch to standards mode; nowadays have to do
that to be in standards mode
... second if want character entities, HAVE to use doctypes -- if can't solve
those issues, doctypes going to be around for a long time to come
RM: that's exactly what problem is
SP: TBL recently started talking down doctypes and i'm not sure why or why he cares
RM: not playing down doctypes per se, but stating no need for doctype
SP: shouldn't be a "must"
RM: just said "remove doctypes" from our specs, not the world
SM: i thought he said remove DTD
RM: what's the diff?
SM: DTD schema declaration
RM: remove doctype requirement, not forcing loading of DTD -- if want to validate, need to keep doctype
SM: reads from TBL -- besides, don't have "must" but "should"
RM: what ascpect of that do you disagree with -- insist on DTDs forever?
SM: M12n 1.1 has to have a DTD -- no other implementation technique; second need DTD to validate
SP: doesn't hurt anyone
SM: if want XHTML+RDFa to work in current browsers have to have announcement mechanism browsers understand, and that is doctype
RM: Shane saying we do need announcement mechanism
SM: for it to work in existing browsers
RM: how does that make a difference?
SP: doctype declaration mark is what browsers use to switch into standards mode
SM: want XHTML document to render properly
RM: standards mode about processing, not about processing xhtml
SM: consistent rendering comes from standards mode
RM: what has to do with RDFa?
SM: nothing -- require for consistency amongst the family -- has nothing to do with RDFa, but XHTML
RM: don't require in RDFa
SM: wg told me to make it a "should" a few months ago
RM: trying to understand what you think we need and why TBL doesn't understand what we need
SP: TBL wants markup that states "this document
has RDFa in it" -- DTD not wanted because "old fashioned" -- our response is
DTD not required, but is quite useful (for validation, for example) -- does
no harm can leave out or include -- also method currently used as marker to
declare RDFa
... if took away would have to invent another markup
SM: have "version" atttribute for that
... all that aside, issue of XHTML family docs and behavior when delivered as
text/html -- another thread; note suggests that way to ensure document works
consistently is to use DTD, follow appendix c (moving to doctype portion), --
if do that, should behave properly and render properly across UAs
SP: do we need to do anything with TAG right now -- this discussion has gone over to RDFa task force, and turned up there as LC comments; should leave issue there to be dealt with
RM: agree
scribe's note: SP's Action Item on RDFa comments disposed (being done by others)
SM: sent status - i think is ready to go, markB had a few comments
RM: ready to go to LC -- just needs transition request
SP: sent transition request last week --
SM: update working draft today
SP: who will send message?
<scribe> ACTION: Steven to send message about CURIEs transition [recorded in http://www.w3.org/2008/03/26-xhtml-minutes.html#action03]
<ShaneM> FYI - RDFa version attribute declaration is <!ENTITY % XHTML.version "XHTML+RDFa 1.0" >
RM: Role Module status?
... can we take to LC today?
SM: as far as i'm concerned ready to go last week -- question remaining relates to CURIEs
MB: discussions offlist about way CURIEs and
Role interact -- my issue is don't think should insist that values that are
non-prefixed are invalid; should let those who import role into host language
should be allowed to do so
... 2 choices -- let docs go through or try and resolve on list so doesn't
haunt us during LC
... as far as timing, LC comments can be incorporated easily, so shouldn't
hold up progress of document
SP: idea of LC is that WG has dealt with all
issues in its ken
... prefer to discuss on list
RM: values of role attribute fixed?
SM: concerns about CURIE draft or how Role uses it?
MB: minor change needs to be made to Role to use CURIEs
SM: thought resolved
RM: thought problem only with Role -- other problems?
<ShaneM> http://htmlwg.mn.aptest.com/htmlwg/curie is the live editors draft
MB: i need to re-check, but need to allow un-prefixed values in CURIE spec
SM: we do that
<ShaneM> curie := [ [ prefix ] ':' ] reference
MB: thought that had changed -- if i review after meeting with SM, can move forward on CURIEs and will raise Role issue on list as requested
RM: close CURIE today -- go to LC or not; role will take as long as takes to obtain agreement
RESOLUTION: CURIEs issues closed - will move forward to LC
<scribe> ACTION: MarkB to once CURIE draft pushed, post to public-xhtml2 list on related Role issues [recorded in http://www.w3.org/2008/03/26-xhtml-minutes.html#action04]
MB: if WG happy with shane and me making changes will do; if not will raise 2 issues on list
RM: hope to get Role resolved next week
... reconvene this time (or later, depending upon where you are) next week