E-mail List Archives
Thread: Pronounced as initials (was RE: WCAG 2 draft and abbreviations)
Number of posts in this thread: 12 (In chronological order)
From: John Foliot - Stanford Online Accessibility Program
Date: Tue, Jun 05 2007 12:40PM
Subject: Pronounced as initials (was RE: WCAG 2 draft and abbreviations)
No previous message | Next message →
Keith Parks wrote:
>
> For instance, a reader ought to be able to tell, through experience
> and context, that the "US" in US Olympic Team is an abbreviation, to
> be pronounced "you ess". But how does the speech synthesizer know
> this? Do they have that level of logic and interpretation built into
> them?
>
> It would seem like a structural tag saying that "These letters are
> not an ordinary word, but are to be pronounced as initials" would be
> helpful, outside of any explanation of what they stand for, which I
> agree ought to be part of regular flow of text, as is typical when
> following proper writing style.
Oh, but that aural style sheets were taken seriously:
<span style="speak:spell-out;">US</span>
[http://www.w3.org/TR/REC-CSS2/aural.html#speaking-props]
It exists already Keith...
JF
---
John Foliot
Academic Technology Consultant
Stanford Online Accessibility Program
http://soap.stanford.edu
Stanford University
560 Escondido Mall
Meyer Library 181
Stanford, CA 94305-3093
Tel: 650-862-4603
From: smithj7
Date: Wed, Aug 22 2007 5:40PM
Subject: Re: WCAG 2 draft and abbreviations
← Previous message | Next message →
Great question.
We have been discussing the same issue at our Florida standards
meetings. In general, using our current but older standards (2003), we
always follow the print version e.g. Individual Employment Plan (IEP)
and then use IEP there after. For typical pages I get, if this format
wasn't followed, I can quickly fix to follow this standard.
However, I also put minutes up on the website. Minutes can't be changed.
There were many abbreviations and/or acroynms in the minutes so I used
the the acroymn tag for all these mysterious letters, after playing
detective for half. I put them in all places. I have done this for
about 2 years (or eight to ten minutes). Two people emailed the first
time they saw them. One liked it, the other was just curious why they
were there. He noted that "everyone" knew what those mysterious letters
meant. I told him the DOE rule for abbreviations and my inablity to
change the minutes and he agreed that this was a good way to meet my
requirements.
Note: I used the acroynm because about 65 percent of our customers are
using IE6. The purpose being two-fold being my website standards and
more important that users know what letter like LOFA mean in the
minutes.
-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Peter Weil
Sent: Thursday, May 31, 2007 10:46 AM
To: WebAIM Discussion List
Subject: [WebAIM] WCAG 2 draft and abbreviations
I know this topic has been discussed previously on this list, but I
still have some quesitons about it.
My colleagues and I are trying to come up with some best practices
for tagging and expanding abbreviations and acronyms. Most copy we
receive contains a large number of these things -- alas, we have no
control over this.
We all agree that including tags with expansions or explanations is
the best technique currently available (see exception below). But we
are still uncertain whether to tag and expand only the first
occurrence or all occurrences (leaving aside the question of how to
accomplish this efficiently). One colleague proposes tagging the
first instance after each header (h1 through h6).
To complicate matters, often the first occurrence in the copy we
receive already contains the expansion -- this satisfies one of the
'acceptable' techniques:
"provide the full form before providing the abbreviated form"
Example: "The United Nations High Commissioner for Human Rights
(UNHCR) was established in 1950 to provide protection and assistance
to refugees."
In these cases, what should we do with additional occurrences? Tag
and expand, tag with no title attribute, or nothing?
This brings up another question: do the abbreviation and acronym tags
(aside from their semantic correctness) in and of themselves help in
any way with accessibility, or is the expansion (title attribute)
always needed to make them useful?
How are others approaching this problem?
--
Peter Weil, Web Developer
University Communications
University of Wisconsin-Madison
Phone: 608-262-6538
Email: = EMAIL ADDRESS REMOVED =
From: Jukka K. Korpela
Date: Thu, Aug 23 2007 12:30AM
Subject: Re: WCAG 2 draft and abbreviations
← Previous message | Next message →
On Wed, 22 Aug 2007, smithj7 wrote:
> In general, using our current but older standards (2003), we
> always follow the print version e.g. Individual Employment Plan (IEP)
> and then use IEP there after.
Such an approach solves the basic problem with abbreviations better than
any markup could possibly do. However, especially in long documents,
readers - particularly those with cognitive disabilites - will have
difficulties in remembering the meanings of abbreviations. Sometimes it's
useful to also provide a list of abbreviations and their expansion,
perhaps on a separate pages. Moreover, an expansion of an abbreviation
should not be expected to present its full meaning to everyone. As any
expression, it may require an explanation. (Think about "SI". That's short
for "Système international". Does the expansion tell what it is about? Or
to take a perhaps extreme example, consider recursive expansions like GNU
= Gnu's Not Unix. :-) )
Abbreviations aren't really that different from other expressions. An
unusual word, or a common word used in an unusual meaning (perhaps as a
technical term completely different from the word's everyday meaning) can
be far bigger an obstacle to understanding than an abbreviation like "USA"
or "IBM".
> However, I also put minutes up on the website. Minutes can't be changed.
They can be annotated. If you think they cannot, you need to write a
separate explanatory document. Markup that may cause some expansion to be
shown in a tooltip or optionally spoken out is tantamount to an annotation
that has, by design, been written so that its content is available to some
users only. So it's a typical compromise: it combines the drawbacks of
both alternatives.
Annotations should be written so that they are available to all and
clearly distinguished from the text proper, especially if the text is
something official. Annotations should be identifiable as made by someone
or some organization, and this is one reason why abbreviation markup won't
do - it's too clumsy to present it that way.
> There were many abbreviations and/or acroynms in the minutes so I used
> the the acroymn tag for all these mysterious letters, after playing
> detective for half.
One of the risks here is that you get the meaning wrong. It is therefore
important that you and only you have been indicated as the source of those
annotations. A wrong annotation should be identified as a wrong
annotation, not an error in the text.
> Note: I used the acroynm because about 65 percent of our customers are
> using IE6.
Does that justify giving semantically wrong information? What happens if
some day some speech browser utilizes <acronym> markup and pronounces,
say, <acronym>IEP</acronym> as a pronounceable word (eye-ep? yep? who
knows?) as it really _should_, if the word "acronym" is taken in its
meaning in cultivated literary English?
--
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/
From: smithj7
Date: Thu, Aug 23 2007 5:20PM
Subject: Re: WCAG 2 draft and abbreviations
← Previous message | Next message →
Thanks for the great comments. Perhaps providing a combination of these
techniques is the way to go. I could start a glossary of terms,
abbreviations, and acroynms adding to them as new documents arrive and
talk to content folks once it is up to add to it. I will continue with
the print version (even if it is dismissed as our standard), and then I
easily do the semantic changes using a search and replace feature for
both acroynms and abbrebiations using the correct term. Then when
semantic mark up becomes available to speech users that will be
available.
I expectionally like the idea of annonating the minutes for acroynms or
abbreviations. I actually did this when one of the minutes came with a
policy indicating changes using colors (committee of blind vendors - low
vision user). So I wrote notations of additions for speech user and
provided notation at beginning of minutes that I was adding such and
such for deleted text and such and such for added text. I hadn't
thought of doing the same for the acroynms and abbreviations. Thanks
again!
-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jukka K.
Korpela
Sent: Thursday, August 23, 2007 2:29 AM
To: WebAIM Discussion List
Subject: Re: [WebAIM] WCAG 2 draft and abbreviations
On Wed, 22 Aug 2007, smithj7 wrote:
> In general, using our current but older standards (2003), we always
> follow the print version e.g. Individual Employment Plan (IEP) and
> then use IEP there after.
Such an approach solves the basic problem with abbreviations better than
any markup could possibly do. However, especially in long documents,
readers - particularly those with cognitive disabilites - will have
difficulties in remembering the meanings of abbreviations. Sometimes
it's
useful to also provide a list of abbreviations and their expansion,
perhaps on a separate pages. Moreover, an expansion of an abbreviation
should not be expected to present its full meaning to everyone. As any
expression, it may require an explanation. (Think about "SI". That's
short
for "Système international". Does the expansion tell what it is about?
Or
to take a perhaps extreme example, consider recursive expansions like
GNU
= Gnu's Not Unix. :-) )
Abbreviations aren't really that different from other expressions. An
unusual word, or a common word used in an unusual meaning (perhaps as a
technical term completely different from the word's everyday meaning)
can
be far bigger an obstacle to understanding than an abbreviation like
"USA"
or "IBM".
> However, I also put minutes up on the website. Minutes can't be
> changed.
They can be annotated. If you think they cannot, you need to write a
separate explanatory document. Markup that may cause some expansion to
be
shown in a tooltip or optionally spoken out is tantamount to an
annotation
that has, by design, been written so that its content is available to
some
users only. So it's a typical compromise: it combines the drawbacks of
both alternatives.
Annotations should be written so that they are available to all and
clearly distinguished from the text proper, especially if the text is
something official. Annotations should be identifiable as made by
someone
or some organization, and this is one reason why abbreviation markup
won't
do - it's too clumsy to present it that way.
> There were many abbreviations and/or acroynms in the minutes so I used
> the the acroymn tag for all these mysterious letters, after playing
> detective for half.
One of the risks here is that you get the meaning wrong. It is therefore
important that you and only you have been indicated as the source of
those
annotations. A wrong annotation should be identified as a wrong
annotation, not an error in the text.
> Note: I used the acroynm because about 65 percent of our customers are
> using IE6.
Does that justify giving semantically wrong information? What happens if
some day some speech browser utilizes <acronym> markup and pronounces,
say, <acronym>IEP</acronym> as a pronounceable word (eye-ep? yep? who
knows?) as it really _should_, if the word "acronym" is taken in its
meaning in cultivated literary English?
--
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/
From: Philip Kiff
Date: Thu, Aug 23 2007 10:10PM
Subject: Re: WCAG 2 draft and abbreviations
← Previous message | Next message →
>> Peter Weil wrote on Thursday, May 31, 2007 10:46 AM:
>>> I know this topic has been discussed previously on this list,
>>> but I still have some quesitons about it.
>>> [snip]
> smithj7 wrote on 22 August 2007 19:26 EDT:
>> Great question.
>>
>> We have been discussing the same issue at our Florida standards
>> meetings.
>> [snip]
Readers following this thread may want to consult the original set of
replies to Peter Weil's question back at the end of May:
http://webaim.org/discussion/mail_archive.php?sort_by=1&;id=10656#10656
Also, my impression from that original thread was that each of the possible
solutions mentioned by smithj7 would be acceptable under WCAG2, including
the one that "proposes tagging the first instance after each header (h1
through h6)". See especially the comments by Loretta Guarino Reid in that
earlier thread for further clarification of the WCAG 2 intent.
Jukka K. Korpela wrote on 23 August 2007:
> smithj7 wrote on 22 August 2007 19:26 EDT:
>> Note: I used the acroynm because about 65 percent of our customers
>> are using IE6.
>
> Does that justify giving semantically wrong information? What happens
> if some day some speech browser utilizes <acronym> markup and
> pronounces, say, <acronym>IEP</acronym> as a pronounceable word
> (eye-ep? yep? who knows?) as it really _should_, if the word
> "acronym" is taken in its meaning in cultivated literary English?
As noted in the original thread at the end of May, there is legitimate
disagreement amongst "cultivated" English language users over the exact
meaning of the word "acronym" and of the precise distinction between an
abbreviation and an acronym.
In the current WCAG 2 draft, <abbr> is identified as the general case: "It
is always appropriate to use the abbr element for any abbreviation,
including acronyms and initialisms. When using HTML 4.01, XHTML 1.0 or XHTML
1.1, initialisms and acronyms may be marked up using the acronym element.
XHTML 2.0 proposes eliminating the acronym element in favor of the more
general abbr element."
See Techniques for WCAG 2.0 - H28: Providing definitions for abbreviations
by using the abbr and acronym elements - Applies to WCAG 3.14
(Abbreviations):
http://www.w3.org/TR/2007/WD-WCAG20-TECHS-20070517/Overview.html#H28
I personally do not think that there is any danger of speech browsers/screen
readers EVER selectively deciding to attempt to pronounce things tagged as
<acronym> and not pronounce things tagged as <abbr>. It is far more likely
that such browsers will develop vocabularies of common
acronyms/abbreviations that they can consult in order to decide how to
pronounce such words, regardless of whether they are coded one way or
another. This is especially true since it appears that the acronym tag is
actually on its way out in XHTML 2 and since abbr is now supported by IE7.
If 65 percent of smithj7's users are still using IE6, then I would argue
that yes, it does justify the use of <acronym> instead of <abbr>. Indeed
for a number of years now some people have resorted to only using <acronym>
for all acronyms, initialisms, and abbreviations due to the desire to
compensate for the failures of various popular MSIE versions. In "semantic"
terms, there is real disagreement about what the "semantic" difference is.
And in practical terms, there are no differences in the way any past or
current screen reader handles <acronym> vs. <abbr>, so there is no "real
world" difference, and the use of <acronym> in place of <abbr> will
certainly not have any effect on "accessibility" in the current or near
future. Several years further into the future a simple find/replace script
will be able to upgrade all the code to abbr if it becomes necessary, but
for now, I think the use of acronym is fully justified in smithj7's case
because of the target customer base. There is nothing less accessible than
code that doesn't work in your browser.
Phil.
From: Jukka K. Korpela
Date: Fri, Aug 24 2007 12:20AM
Subject: Re: WCAG 2 draft and abbreviations
← Previous message | Next message →
On Fri, 24 Aug 2007, Philip Kiff wrote:
> Also, my impression from that original thread was that each of the possible
> solutions mentioned by smithj7 would be acceptable under WCAG2, including
> the one that "proposes tagging the first instance after each header (h1
> through h6)".
Why would that matter? WCAG 2 is just a draft, which may never turn into a
specification, still less a widely approved one. Even if it does, it
should serve accessibility work, not vice versa.
> As noted in the original thread at the end of May, there is legitimate
> disagreement amongst "cultivated" English language users over the exact
> meaning of the word "acronym" and of the precise distinction between an
> abbreviation and an acronym.
The bottom line is that <acronym> has no useful defined semantics but may
understandably be taken in the dictionary sense. It is semantically
_worse_ than <span>, which by definition lacks all defined semantics.
> See Techniques for WCAG 2.0 - H28: Providing definitions for abbreviations
> by using the abbr and acronym elements - Applies to WCAG 3.14
Just because they keep the misguided and misguiding idea even in the new
draft doesn't mean we should use such markup. Their effect on
accessibility is generally negative, and the possible gains are better
achieved using other methods.
> I personally do not think that there is any danger of speech browsers/screen
> readers EVER selectively deciding to attempt to pronounce things tagged as
> <acronym> and not pronounce things tagged as <abbr>.
Yet such ideas were an essential part of the original motivation for
including those elements into HTML. It was a wrong idea and does not
become any better by time.
> If 65 percent of smithj7's users are still using IE6, then I would argue
> that yes, it does justify the use of <acronym> instead of <abbr>.
If you just want the tooltip effect, then <span> is superior to <acronym>.
But why would you leave anything essential dependent on a tooltip effect
that is not required by any specification, typically shows the text in a
tiny little window in a tiny little font for a tiny little time, and may
disturb people more than help them?
If you just want screen readers to read some text optionally, shouldn't
you consider the fact that the vast majority of users is not using screen
readers? Besides, the text will be missed by many screen readers too, e.g.
because their software has been configured not to read the text?
--
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/
From: Philip Kiff
Date: Fri, Aug 24 2007 8:50AM
Subject: Re: WCAG 2 draft and abbreviations
← Previous message | Next message →
Jukka K. Korpela wrote on Fri 24 August:
> On Fri, 24 Aug 2007, Philip Kiff wrote:
>> Also, my impression from that original thread was that each of the
>> possible solutions mentioned by smithj7 would be acceptable under
>> WCAG2, including the one that "proposes tagging the first instance
>> after each header (h1 through h6)".
>
> Why would that matter? WCAG 2 is just a draft, which may never turn
> into a specification, still less a widely approved one. Even if it
> does, it should serve accessibility work, not vice versa.
Well, to be fair, the subject line of the thread is "WCAG 2 draft and
abbreviations". I understood that the original poster sought advice with
respect to interpretations of the WCAG 2 draft and the best practice
techniques.
> The bottom line is that <acronym> has no useful defined semantics but
> may understandably be taken in the dictionary sense. It is
> semantically _worse_ than <span>, which by definition lacks all
> defined semantics.
[...]
> Just because they keep the misguided and misguiding idea even in the
> new draft doesn't mean we should use such markup.
[...]
> It was a wrong idea and does not
> become any better by time.
[...]
> If you just want the tooltip effect, then <span> is superior to
> <acronym>.
Your position seems to be that in the best practice scenario, nothing should
be used? And then at the next step down from the best practice, neither
<abbr> nor <acronym> should be used: since <span> would be better? And then
at the third step down, if developers decide to use one of those elements,
then they should use <abbr> only, or <abbr> for abbreviations and <acronym>
only for pronounceable initialisms?
I can see the argument for the latter two points, but I disagree with the
notion that using nothing is better than abbr/acronym or that <span> is a
better tag to use. In general, it seems to me that the best practice
recommendation is to use <abbr> instead of <acronym>, as you suggest (if you
insist on using at least one of those elements). However, I think that the
best practice recommendation should be modified based on one's target
audience when necessary.
With respect to the choice of whether to use <acronym> or <abbr>, I think
you are making far too much of the "semantic" difference between <abbr> and
<acronym>, and the ways that those semantic differences may have an effect
on a site visitor/screen reader user, now and in the future. My point is
that this semantic difference will have NO effect on a current screen reader
user or visual browser user and so it is not really that important to
uphold. This is especially true in the case of a site where 65% of their
target audience are using IE6.
The idea of "semantic" HTML does not mean that HTML code has all of a sudden
become a language full of absolute dictionary meanings and definitions, it
is still just code: the "semantic" part depends on human interpretation and
there continue to be arguments of the supposed "semantic" meanings of
various elements: ul vs. ol (A-Z lists?), h1 vs. h2 (subheadings, site
titles?), dl vs. table (what is a "definition list"?), address vs. p (which
parts should be marked address, and how?), etc. The differences in
interpretation of <abbr> and <acronym> are just one more in a list of
"semantic" ambiguities in X/HTML, and in my opinion those differences are
relatively unimportant when it comes right down to it. It is much more
important to serve up your pages with code that works in the most popular
browser used by your site visitors.
I am somewhat sympathetic to the argument that it would be better to use
nothing at all and ignore the <acronym> and <abbr> elements entirely;
however, I think you have only managed to construct (here and elsewhere) a
weak case for that position, and I am not yet convinced by your arguments
along those lines. In particular, I find the following counterarguments
more convincing:
- some users find the tooltip acronym/abbr expansions useful, particularly
in the case of long documents with many acronyms whose expansions are only
given once in the text (this is based on anecdotal evidence)
- no research has been done to demonstrate that such coding is confusing or
causes problems for anyone
- acronym and abbr are part of both the HTML and XHTML specs, and abbr at
any rate does not appear to be going away
- the dotted underline below abbr/acronym has become a common "standard" in
modern browsers, so it is becoming less and less strange to users
- advanced users of screen readers or visual browsers can customize their
browsers to display acronym/abbr however they want, whereas there is no way
for them to customize the display of <span> without a standard in place to
identify which spans are used to expand acronyms/abbreviations
- web page content is not simply print content transferred to the web: the
web is a different medium that offers additional ways of conveying content,
and just because a document and its abbreviations and acronyms should be
completely understandable without *requiring* acronym/abbr tags, does not
mean that those tags cannot enrich a document in an electronic medium
- in the future, a JavaScript or some other script could be developed to
read the DOM and produce a pop-up list of acronyms and abbreviations on the
fly, whereas such a list could not be produced if you used span
- in the future, if <acronym> is entirely eliminated, then there will no
longer be any semantic distinction in coding between acronym and abbr, so
the question of the use of acronym instead of abbr will become an even more
"academic" question that it is currently
Phil.
From: Alastair Campbell
Date: Fri, Aug 24 2007 9:20AM
Subject: Re: WCAG 2 draft and abbreviations
← Previous message | Next message →
Philip Kiff wrote:
> "With respect to the choice of whether to use <acronym> or <abbr>, I
> think you are making far too much of the "semantic" difference
> between <abbr> and <acronym>"
I have to agree. Looking forward, what you 'semantically' want from an
interface point of view is an element that designates some text might
need more explanation, which then leads to (paraphrasing the other
points):
- Enabling user customisation.
- Automatically creating glossaries or other aids based purely on the
content.
In HTML5 terms (*not* trying to stir up Mr Foliot ;), I can't see a
"use-case" for having both.
I used to just use acronym, due to IE's lack of support. Now I'm leaning
towards just using abbr, as it has the more general meaning of the two,
and you can 'fix it' for IE:
http://juicystudio.com/article/fixing-ie-quotes.php
Kind regards,
-Alastair
--
Alastair Campbell | Director of User Experience
Nomensa Email Disclaimer:
http://www.nomensa.com/email-disclaimer.html
From: Tim Beadle
Date: Fri, Aug 24 2007 11:10AM
Subject: Re: WCAG 2 draft and abbreviations
← Previous message | Next message →
On 24/08/07, Alastair Campbell < = EMAIL ADDRESS REMOVED = > wrote:
> In HTML5 terms (*not* trying to stir up Mr Foliot ;), I can't see a
> "use-case" for having both.
What about dfn - another element describing word(s) with a form of expansion?
> I used to just use acronym, due to IE's lack of support. Now I'm leaning
> towards just using abbr, as it has the more general meaning of the two,
> and you can 'fix it' for IE:
> http://juicystudio.com/article/fixing-ie-quotes.php
That's a useful link - thanks.
Tim
From: Alastair Campbell
Date: Fri, Aug 24 2007 11:20AM
Subject: Re: WCAG 2 draft and abbreviations
← Previous message | Next message →
Tim Beadle wrote:
> What about dfn - another element describing word(s) with a form of
> expansion?
Good point, could that be the general case?
<dfn title="expansion">term that needs explanation</dfn>
Kind regards,
-Alastair
--
Alastair Campbell | Director of User Experience
Nomensa Email Disclaimer:
http://www.nomensa.com/email-disclaimer.html
From: Kroon.Kurtis
Date: Fri, Aug 24 2007 1:00PM
Subject: Re: WCAG 2 draft and abbreviations
← Previous message | Next message →
On Fri, 24 Aug 2007, Jukka Korpela wrote:
> On Fri, 24 Aug 2007, Philip Kiff wrote:
> ***
>> I personally do not think that there is any danger of speech browsers/screen
>> readers EVER selectively deciding to attempt to pronounce things tagged as
>> <acronym> and not pronounce things tagged as <abbr>.
> Yet such ideas were an essential part of the original motivation for
> including those elements into HTML. It was a wrong idea and does not
> become any better by time.
If user agents supported the _speak_ properties from CSS 2.0 -- which has been
around since *1998*, after all -- we could state exactly how we wanted each one
pronounced, viz.:
acronym {speak: normal;}
abbr {speak: spell-out;}
We could even change it depending on context:
#mainContentArea acronym.firstInstance {speak: spell-out;} /* Why? */
abbr.withDigits {speak: spell-out; speak-numeral: digits;}
Of course, this is all hypothetical -- but isn't WCAG 2.0 still hypothetical as
well?
Kurtis Kroon
Franchise Tax Board
State of California
916-845-5603
------------
mailto: = EMAIL ADDRESS REMOVED = | http://www.ftb.ca.gov/
ASD:CPB:WB&MS:WBM:SSA
From: John Foliot - Stanford Online Accessibility Program
Date: Fri, Aug 24 2007 1:10PM
Subject: Re: WCAG 2 draft and abbreviations
← Previous message | No next message
Alastair Campbell wrote:
> In HTML5 terms (*not* trying to stir up Mr Foliot ;), I can't see a
> "use-case" for having both.
??? I suspect you are just having fun with me, so I will grin along with
you.
For the record, I have nothing against the emergence of HTML 5, and rather
hope that it addresses existing shortcomings within HTML 4.01 (like actually
coming up with a better solution than accesskey, so that we *can* extend
enhanced keyboard support without the current headaches that most know I go
on and on about...)
My concern is over the current process, and the apparent highjacking by some
Working Group members who feel they have a lock on what should and should
not be in the new spec, using their criteria without consideration of
others.
But I'll back down now...
Cheers!
JF