See also: IRC log
<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
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 - http://lists.w3.org/Archives/Public/public-xhtml2/2009Feb/0029.html
RM: not done the XML Events 2 related actions;
shane not here to update
... 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
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 check
<scribe> ACTION: GJR - ensure that XHTML Vocab Document in sync with ARIA 1.0 Last Call draft are in sync [recorded in http://www.w3.org/2009/02/11-xhtml-minutes.html#action01]
<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
http://www.w3.org/1999/xhtml/vocab/
RM: yes
... pragmatic move on both WG's parts
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
elements
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 place
<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 sufficient
... 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 MOD
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 work
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 http://www.w3.org/2009/02/11-xhtml-minutes.html#action02]
<trackbot> Created ACTION-50 - - 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 [on Gregory Rosmaita - due 2009-02-18].
RM: short time left -- markus, could you talk with us about M12n and 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
framework
... 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
ADJOURN
This is scribe.perl Revision: 1.133 of Date: 2008/01/18 18:48:51 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/RS:/RM:/G Succeeded: s/rather than define/in addition to defining/ Succeeded: s/send summation of discussion (this is what we need from language point of view and good practices bad practices) with examples/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/ Found Scribe: Gregory_Rosmaita Found ScribeNick: oedipus Default Present: Roland, Gregory_Rosmaita, mgylling, +0468645aaaa, +0468645aabb, Tina Present: Gregory_Rosmaita Roland Tina mgylling Regrets: Mark_Birbeck Shane_McCarron Steven_Pemberton Agenda: http://lists.w3.org/Archives/Public/public-xhtml2/2009Feb/0024.html Found Date: 11 Feb 2009 Guessing minutes URL: http://www.w3.org/2009/02/11-xhtml-minutes.html People with action items: gjr WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]