W3C home > Mailing lists > Public > public-xhtml2@w3.org > December 2008

[XHTML] Minutes: 2008-12-02

From: Gregory J. Rosmaita <oedipus@hicom.net>
Date: Wed, 3 Dec 2008 15:56:47 +0000
To: public-xhtml2@w3.org
Message-Id: <20081203155534.M40653@hicom.net>

aloha, all!

minutes from today's XHTML2 Working Group Teleconference can be 
found as hypertext at:


and as an IRC log at:


and as plain text following my signature; as usual, any errors, 
omissions, mis-attributions, clarifications and the like should be 
logged by replying to this announcement on-list...


                                   - DRAFT -

                      XHTML2 Working Group Teleconference

03 Dec 2008


See also:
 * IRC log: http://www.w3.org/2008/12/03-xhtml-irc
 * Previous Minutes: http://www.w3.org/2008/11/26-xhtml-minutes.html
 * Agenda Planning Tracker: http://www.w3.org/MarkUp/tracker/agenda


          Gregory_Rosmaita, Roland, ShaneM, Markus_Gylling, Alessio
          Mark_Birbeck, Steven




     * Topics
         1. Announcements, News, Hot Topics, Agenda Review
         2. Oustanding Actions -
         3. Access Module
         4. XML Events 2: status?
         5. XHTML MIME type: Status?
         6. Notes from Tina on XHTML Mime
         7. XHTML2
     * Summary of Action Items

Announcements, News, Hot Topics, Agenda Review

   Agenda Planning Tracker: http://www.w3.org/MarkUp/tracker/agenda

   <ShaneM> having difficulties with headset

   RM: brief update on CURIE syntax - had transition call yesterday, got
   ok to transition, still paperwork to be done, should move forward

Oustanding Actions - http://www.w3.org/MarkUp/tracker/actions/open

   RM: XML Events 2 haven't done; DOM discussed yesterday - will include
   action 40 in status update for HTC
   ... features document?

   SM: none are completed unless marked "pending review"

   RM: http://www.w3.org/MarkUp/tracker/actions/11 - policy statement on
   migration and inclusion

   SM: started to do, but could decide where to put

   RM: isn't there another action for that
   ... close action 11
   ... http://www.w3.org/MarkUp/tracker/actions/18 - changes in Mime
   ... substantive note from Tina -

   SM: would rather do when tina here

   RM: if no tina at meeting, please respond on-list
   ... action 18 should be closed
   ... http://www.w3.org/MarkUp/tracker/actions/33 - should be closed

   RESOLUTION: Actions 11, 13 and 18 are closed

   RM: action 13 might be worth some discussion

   SM: delegated it; will ping and update

   RM: action 15 - not have separate implements module - fold into XHTML2
   - is that correct?

   SM: made note to that effect in action
   ... leave action until finished

   RM: action item from GJR -

   GJR: pf said: "The word "similar" was inserted to satisfy general
   requirements for HTML processing, since the Role module includes
   low-level processing specifics, which can't be ported to HTML5;
   therefore, in order to enable ARIA in HTML5 it is necessary to define
   low-level DOM parsing whilst still accepting same content, with same
   accessibility result. Of course, if one is using XHTML2 to author a
   document, then that author would and SHOULD use the Role Module

   RM: all ARIA attributes can be used without prefix; defined for us and
   in XHTML vocab
   ... for ARIA terms there is no namespaced vocabulary

   GJR: agree with RM, think that PF punted

   SM: don't know what is going to be in HTML5

   GJR: HTML5 e.t.a. is 2012 at earliest

   RM: carry on and ignore -- given WAI everything asked for; shouldn't
   waste our cycles on this
   ... de facto implementation of HTML5 by developers
   ... happy to consider item complete

   <mib_jqd0sf> ops

   SM: during LC review, can submit formal objection because should be
   using Role attribute PF helped define

   GJR: would support that

   RM: any other actions finished?

Access Module

   RM: waiting for comments

   GJR: i18n issues?

   <Tina> I'll send my comments on the ACCESS module by Monday

   SM: comment from forms; Steven brought up in Forms WG - John Boyer
   (chair) supposed to send us note; can live with it if multiple IDs in
   XForms and XHTML2 synced; thing XForms comment closed

   RM: can close XForms comment
   ... action 35 is complete

   SM: everything regards Access closed out; implementation report and
   disposition of comments all ready; need to wait until CURIEs reaches
   CR for this to reach CR because references CURIE

   RM: same with Role?

   SM: yes, not certain if SP has sent in transition request for the 3

   RM: haven't seen them
   ... resolved to request CR Transition

XML Events 2: status?



   RM: discussed last week - going back to DOM2 - have to inspect DOM2
   spec - anyone done that?

   SM: no

   GJR: no

XHTML MIME type: Status?


   RM: need to get done for XHTML 1.0 SE and 1.1 PER will point to that

   SM: issue: XML 1.0 Fifth Edition became a rec yesterday
   ... changes rules / definition of ID - changes what chars are legal in
   ID; historically have just transitioned to current version of XML (any
   recs we put out use current XML edition), but what are rammifications
   of changing @id to make more inclusive - with our documents, some
   point to fourth edition, some to fifth

   RM: reads errata for fourth edition

   <mgylling> Before the fifth edition, XML 1.0 was explicitly based on
   Unicode 2.0. As of the fifth edition, it is based on Unicode 5.0.0 or
   later. This effectively allows not only characters used today, but
   also characters that will be used tomorrow.

   RM: due to unicode changes?

   SM: previously malformed documents now ok; invalid documents now valid
   -- don't understand

   RM: main characters has changed

   <mgylling> http://blog.jclark.com/2008/10/xml-10-5th-edition.html

   MG: there is a blog entry from James Clark explaining why he thinks
   fifth edition broken - was controversial

   SM: jame's blog is exactly what i thought/concluded
   ... good news (sort of) - always made dated references to 1.0
   (reference edition numbers); we are dependent upon namespaces, and
   they are not referenced
   ... don't understand rammifications, but they keep me awake at night

   RM: if stay with Fourth Edition, and say that those in Fifth Edition
   are ok, but a SUB-SET of those in Fourth Edition

   SM: hope change is forward compatible

   RM: should leave the pointer alone for XML Fourth Edition
   ... if get through PR review and asked why not Fifth, we say "prove to
   us won't cause problems"

   SM: reasonable

   GJR: plus 1

   <alessio> +1

   RM: keep status quo: publish our specs pointing to XML 1.0 Fourth
   Edition, until becomes an issue, if becomes and issue



   SM: major change is unicode related

Notes from Tina on XHTML Mime

   RM: same mistakes i had found

   SM: fixed broken internal links
   ... compatibility guidelines: i know what problem i was trying to
   solve with sentence in question: remind validation people at W3C that
   shouldn't validate against this

   RM: could be useful to remind of constraints

   <alessio> for tina and all... I write a note (in italian) on IWA
   Italy's blog related to tina's article:

   SM: don't like suggested wording: is a non-sequitor
   ... "TOPIC: XHTML MIME type: Status?


   Tina's comment: ""It contains no absolute requirements, and should
   NEVER be used as

   the basis for creating conformance nor validation rules of any sort.


   RM: constraint over and above language definition; could write style
   ... replace paragraph with something less dogmatic

   SM: accept suggestion for example 3 - don't use P

   RM: "A.4. Embedded Style Sheets and Scripts
   ... didn't we originally say to avoid inline style and scripts?

   SM: she's attempting to make more assertive, i believe
   ... trying to explain why suggested trick for embedding works
   ... we can explain that

   RM: make clear that is explanation; don't have to if don't want to

   SM: A.5 - generic advice; i think has to do with XML versus HTML

   "This sounds like generic advice for writing markup, rather then
   something relevant to the differences between XHTML and HTML. I could
   be mistaken and would welcome pointers to the relevant parts of the
   specifications if so."

   RM: might be useful if each of these assertions in A.5 are linked

   SM: they are

   RM: don't show in ToC

   SM: no don't show in ToC

   RM: linebreak attribute values

   SM: in XML attribute values are ...

   MG: whitespace neutralized?

   SM: yes

   RM: isn't that part of rationale? ensure on single line isn't bad

   SM: don't remember why did in first place - tina wants rationale -
   thought had to do with whitespace normalization

   <mgylling> If the attribute type is not CDATA, then the XML processor
   MUST further process the normalized attribute value by discarding any
   leading and trailing space (#x20) characters, and by replacing
   sequences of space (#x20) characters by a single space (#x20)

   MG: section 3.3.3 of XML spec
   ... depends on type of attribute; if not CDATA discusses discarding
   leading and trailing space

   RM: option for collapse as well?

   MG: 3.3.3 says replace XML def of whitespace by single space only;
   linebreaks "normalized" to single space, leading or trailing

   SM: section 2.1.1 on end of line handling
   ... end of lines normalized even if inside attribute value
   ... turns linefeeds into spaces

   RM: read section 3.3.3 and 2.1.1 and best to avoid those situations
   since don't know what non-XML parsers would do
   ... A.11 - "Perhaps an example showing how to convert to lower case
   before checking would help clarify this for some people?"

   SM: do ensure that attribute names ... are case insensitive
   ... can show people how to call to lower

   RM: ok

   SM: A.25 - i know answer and will send it to her
   ... A.26. - "to justify removing accessiblity feature..." -- we aren't
   removing, we are telling people not to do it -- same problem as

   RM: deal with NOSCRIPT in whatever answer you send to tina

   SM: Example Document concerns: good point about style element (no bad
   stuff to escape) - rather than remove CDATA markers, should put bad
   stuff in
   ... final comment - grouping selector -

   RM: because HTML and BODY elements are identical, can define style
   once using "html,body { }"

   <Roland> html, body {background-color: #e4e5e9; }

   RM: list, not heirarchy

   SM: right
   ... have bunch of changes to make - between last publication and now,
   pub rules have changed for Notes - additional reqs on Note we need to
   satisfy; will make process changes along with changes stemming from
   tina and our discussion of it

   RM: use of ABBR or ACRONYM

   GJR: have proposed INIT (initialism)

   SM: will fold in WG's response to Tina's comments into Mime today
   along with other pub-related stuff


   RM: question on "do we need nl?" - motivation, wanted navigation, but
   maybe use "nav" as a section - more than list - complete block, like a

   GJR: similar to Role/ARIA concept of "nav"

   RM: yes, big major area, not just detail, but block of navigational
   ... look at way NAV is defined when return to question:
   ... would nav obviate need for NL via specialized container

   SM: had action to send out conversation starter


   RM: ol role="nav" versus nl - will reply and through into mix that
   this is bigger question: NAV as structural element; will kick off
   conversation by replying to shane's note

   <Tina> I have a half-finished reply to Shane's conversation starter

   SM: point i was trying to make is have diff mechanisms to satisfy diff
   needs; should think about needs

   GJR: positive "yes!" reaction to shane's post


Summary of Action Items

   [End of minutes]
Received on Wednesday, 3 December 2008 15:57:30 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:30:31 UTC