W3C home > Mailing lists > Public > public-xhtml2@w3.org > February 2009

minutes: XHTML WG weekly telecon 2009-02-11 [draft]

From: Gregory J. Rosmaita <oedipus@hicom.net>
Date: Wed, 11 Feb 2009 16:02:42 +0000
To: public-xhtml2@w3.org
Message-Id: <20090211160059.M90412@hicom.net>


minutes from today's XHTML2 Working Group Teleconference are available
as hypertext at:


and as an IRC log at


and as plain text following my signature -- as usual, please log any 
errors, mis-attributions, clarifications and the like by replying to 
this announcement on-list

note that since there were only 4 of us on the call, no resolutions
were reached, although we did have a fruitful conversation on 
several XHTML2- and M12n- related issues...

there were 2 action items assigned at the teleconference, both on

   ACTION: GJR - ensure that XHTML Vocab Document in sync with ARIA
   1.0 Last Call draft are in sync [recorded in

   ACTION: GJR - send summation of modification markup discussion 
   (this is what we need from a declarative markup point of view,
   a natural language point of view, and propose good practices 
   and bad practices) with examples [recorded in

finally, apologies to alessio -- i received his notice of regrets
due to technical problems after i had dismissed RRSAgent, so his
name is missing from the "Regrets" list



                                   - DRAFT -

                      XHTML2 Working Group Teleconference

11 Feb 2009


   See also: IRC log [http://www.w3.org/2009/02/11-xhtml-irc]


          Gregory_Rosmaita, Roland, Tina, mgylling

          Mark_Birbeck, Shane_McCarron, Steven_Pemberton




     * Topics
         1. Getting Started & Agenda Additions/Requests
         2. Action Item Review
         3. ARIA and XHTML Vocab
         4. XHTML 2 Issues
         5. Modularization and the XHTML Family
     * Summary of Action Items

   <trackbot> Date: 11 February 2009

   <scribe> Scribe: Gregory_Rosmaita

   <scribe> ScribeNick: oedipus

   previous: http://www.w3.org/2009/02/04-xhtml-minutes.html

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

Getting Started & Agenda Additions/Requests

   RM: steven may on be able to participate via IRC due to attendance at
   Forms F2F

   GJR: ensure alignment of ARIA roles and XHTML Vocab document -

Action Item Review

   RM: not done the XML Events 2 related actions; shane not here to
   ... not sure of status of steven's open actions
   ... haven't seen the transition request

   GJR: shane mentioned that he had 4 PER drafts in his regrets notice

   RM: don't think any actions can close today

ARIA and XHTML Vocab

   GJR: vocab doc has gotten out of sync with the ARIA spec; PFWG will be
   voting today to send the draft at http://www.w3.org/wai/pf/aria
   ... noticed that there were at least 1 or 2 roles missing -- including
   the "math" role
   ... i emailed shane about it directly

   RM: point of section is whatever ARIA wants it to be; so what ARIA
   says, that's what they should be

   GJR: didn't want to fall through the cracks


   10 February 2009 Editor's Draft of ARIA

   GJR: so far only one missing for sure is "math" -- GJR will quintuple

   <scribe> ACTION: GJR - ensure that XHTML Vocab Document in sync with
   ARIA 1.0 Last Call draft are in sync [recorded in

   <trackbot> Created ACTION-49 - - ensure that XHTML Vocab Document in
   sync with ARIA 1.0 Last Call draft are in sync [on Gregory Rosmaita -
   due 2009-02-18].

   RM: ARIA document to go to last call

   MG: the ARIA spec doesn't rec the CURIE spec, right? impllications?

   GJR: as i understand it, is that the CURIE spec when we were drafting
   ARIA was under an existential assault
   ... bin of ideas for ARIA 2.0 includes support for CURIE

   RM: in default namespace -- doesn't need referrencing

   MG: all ARIA roles are going into the XHTML Vocab document


   RM: yes
   ... pragmatic move on both WG's parts

XHTML 2 Issues

   RM: shane not here, so may be tricky; could open discussion on INS,
   DEL and marking up changes in documents

   MG: discussed a few telecons ago -- decision to reintroduce elements
   in addition to defining attribute values

   RM: where should allow INS and DEL to be specified

   TH: inline content
   ... avoid unecessary SPAN to mark change with attribute

   RM: not sure that we came to firm conclusion; INS and DEL - what is
   its scope - can it nest new paragraph, new div, etc.
   ... put into text module was suggestion -- same module with paragraph

   GJR: so are we discussing retention of the "Flow" element concept

   RM: that's the difficulty; can only be used in specific places; if on
   containers, should allow properties on containers (sections or DIVs)
   that say this section is inserted or this is deleted
   ... might want both ways to do this; just add attribute to structural

   GJR: a) a means of marking editorial changes;

   b) a means of classifying an editorial change;

   c) a means of conveying when and by whom the change was affected;

   d) a recognition that things are not black and white, but a thousand

   shades of grey

   GJR: basis of my position is that a single element would be the
   easiest solution

   RM: my experience in XML spec easier to say, "here i am opening a new
   DIV and add attribute rather than using an INS element

   GJR: MOD or whatever would be the structural element

   <Roland> <div diff="add"> . . .

   <Roland> <div><ins> . . .

   TH: still good idea to avoid semantically empty elements in examples
   -- can we use P instead of DIV?

   RM: might consider semantically meaningless, but used all over the

   <Roland> <p diff="add"> . . .

   GJR: a lot of mashups will be served with DIVs or as DIVs

   <Roland> <p><ins> . . .

   TH: can use DIV to cover a large section of modified text; too much
   use of SPAN and DIV --

   RM: easier to think that i need new paragraph and property of P added
   and add other info with RDFa in the paragraph

   TH: only problem is more than one attribute needed: who did it; what
   was changed?

   RM: have that in RDFa

   GJR: agree

   TH: how expressed on specific element, such as P
   ... does RDFa have something that says this is what was, this is what
   new paragraph is; need more info than just "this has been changesd

   RM: much easier to use INS and DEL -- simple binary straightforward

   GJR: no problem with INS and DEL, but think need MOD

   TH: inline, use MOD with attribute to state how modified; want to
   avoid using attributes only for this so authors are tempted to use
   SPAN and DIV to indicate; INS and DEL or MOD fine with me

   GJR: understand and appreciate caution

   TH: MOD gets complicated - this is added this is deleted; MOD needs 2
   sets of data -- what was, and what is; if can do with RDFa, fine, but
   don't think need that much complexity

   GJR: MOD springs from the diffuclty i have always when attempting to
   parse auarally a DIFF docuemnt
   ... was successful in getting the W3C DIFF generator to use INS and
   DEL instead of SPAN
   ... for spelling or grammar change do you really want to have both the
   deleted and inserted text even though 90% of content is same?

   TH: would say yes, based on fact that CSS word-wrap property -- MS
   suggests as arbitrary break point; in some languages, that can change
   contents -- can't do unless have dictionary in UA
   ... spelling change in document very subtle, but can completely change
   meaning of paragraph, would like to know what is there -- especially
   if something there, referred to and chaanged again

   GJR: one strategy for that is to use the global @src to point to the
   earlier wording in an earlier draft for minor edits

   TH: almost agree there -- INS and DEL or MOD are not set up for
   complicated document history
   ... agree with idea - use INS and DEL add history by linking to it,
   need to say this isn't a regular @src but a link to the history
   ... MOD with @src would be handled differently than on other elements

   RM: number of different themes

   <Roland> <p diff="add">I will.</p><p diff="del">I will not.</p>

   <Roland> <p diff="chg">I will.</p>

   <Roland> <ins>I will.</ins><del>I will not.</del>

   <Roland> <mod>I will.</mod>

   RM: INS and DEL, INS, DEL and MOD, or just MOD -- MOD alone not
   ... rather mark add this delete that
   ... MOD or @chg don't know what was there before, just know changed;
   don't have situation if have binary INS and DEL
   ... integrated and deleted in one place with INS and DEL, but not with

   TH: RM's example very good; like to have revision handling mechanism
   spelt out

   RM: process of change -- delete or add things -- that's how keyboards

   GJR: what about changing spelling of one word

   RM: old word should be deleted and new word should be added -- not
   change in letter, but in word

   GJR: i'm thinking about the hell that it is trying to keep up with
   DIFF markings especially on wiki pages
   ... course of last resort for sanity's sake is document source

   RM: marking up changes as much a part of good design as anything else,
   can be done badly or can be done well

   TH: DIFF documents very binary -- markup what taken out and what is
   put in; if have long piece of code or content to make sense in
   context, wouldn't work if each UA read paragraph, then stopped in the
   middle and says a word 2 times; but no more helpful if have to read
   paragraph twice

   RM: i would like it to read what i've got and there has been a change
   -- don't want to see diff marks in many cases -- choice by user --
   show me the history, what has changed --
   ... sympathize if have to use TTS to read a DIFF marked document

   GJR: strategy used to process a DIFF document aurally is an ad hoc use
   of a screen reader's "skim" feature, in which one can set basic font
   characteristic parameters so that only content that meets a specific
   criterion is spoken
   ... but in essense, that means that one is actually processing the
   content multiple times to extract what one would like to be able to
   parse in one go
   ... screen reader bug is can only recognize a limited pallate of color
   names, only Orca gives change to filter by color codes

   <Roland> <ins>dog</ins><del>dig</del>

   <Roland> d<ins>o</ins><del>i</del>g

   <Roland> <mod>dog</mod>

   RM: what would we consider good practice
   ... how to deal with questions: many means of doing this

   <Roland> d<mod>o</mod>g

   RM: all of the above examples are possible, but what is easiest to
   author, read, listen to
   ... prefer first method - inserted correction and marked incorrect
   spelling with DEL
   ... should be dealing with words, phrases paragraphs

   TH: prefer DEL before INS
   ... if have screen reader can filter it to ignore DEL

   <Roland> <del>dig</del><ins>dog</ins>

   GJR: that would work, and in addition if there was a cue from the AT
   that text is marked as INS, then a user could stop, and query for the
   characteriscs of content that is marked DEL to get context
   ... in flow of reading would want to suppress that, but still needs to
   be available to user on user request/query

   RM: still leaves question -- what happens when in middle of words

   GJR: have sympathy for word, phrase limitation
   ... would like to avoid internal use of modidifier element inside a
   word to encase a single letter or group of letters

   TH: agreement there

   proposed resolved: modified text must be at least a word?

   TH: speech browser should look for modified attribute on section or
   paragraph and skip according to user preference

   RM: suggest that GJR attempt to write up where we've got to at end of
   discussion as proposal for discussion next week
   ... much easier to work with examples

   <scribe> ACTION: GJR - send summation of discussion (this is what we
   need from language point of view and good practices bad practices)
   with examples [recorded in

   <trackbot> Created ACTION-50 - - send summation of discussion (this is
   what we need from language point of view and good practices bad
   practices) with examples [on Gregory Rosmaita - due 2009-02-18].

   RM: short time left -- markus, could you talk with us about M12n and
   XHTML family

Modularization and the XHTML Family

   MG: overarching theme: take XHTML m12n in a direction which caters
   more for language designers than it has done before; allow ability to
   express sub-sets of complliance modules being imported
   ... stumble upon idea working in DAISY context with XHTML modules, but
   believe has generic value
   ... changing scope of m12n in way that expands potential audience of
   ... embryonic idea is that there is a way of restricting
   sub-set-ability so not to allow content models that are distortions;
   conssistency of functionality
   ... discussed with Shane over phone; one approach: have abstract
   definitions which are currently tabular, add a column to show module
   where sub-setting is allowed
   ... need to try out concretely to ascertian how and if it works and
   most effective and balanced solution

   RM: reasonable thing to do; come across this difficulty when OMA
   trying to create profile using legacy module -- did anyway even though
   m12n framework doesn't allow -- technically not valid, but
   pragmatically workable

   MG: DAISY would do the same -- utilize XHTML module sets as language
   author; number of compliance grammers needs to grow by embracing this
   way of using it as well

   RM: grammar is small part of it; number of documents which will be
   valid against super-set will be greatly increased; grammars only a
   means to an end to create documents

   MG: risk is UAs being developed that cater only to sub-set

   RM: already in situation where UA devs support only bits in which they
   are interested already

   MG: fait accompli, true, just don't want to make worse

   RM: reached end of time for today
   ... any burning issues?

   GJR: will alert the WG results of ARIA LC vote

   RM: i will be on holiday next week, steven will probably chair

   TH: regrets for next week


Summary of Action Items

   [NEW] ACTION: GJR - ensure that XHTML Vocab Document in sync with ARIA
   1.0 Last Call draft are in sync [recorded in
   [NEW] ACTION: GJR - send summation of discussion (this is what we need
   from language point of view and good practices bad practices) with
   examples [recorded in

   [End of minutes]
Received on Wednesday, 11 February 2009 16:03:22 UTC

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