Re: Including content modes in 4.1

"Fonts", "Character encodings", "Character sets" etc are orthogonal
to the problem - current Hebrew fonts include both characters and
marks in all character set encodings. I suggested "content modes"
precisely because that phrase does not have a pre-existing meaning.
I do not think that "usage" would be understood correctly;
"usage" in current usage (?!) refers to vocabulary and syntax, not to
phonetic hints (which is what vowel marks in semitic and tone marks in
east-asian languages are used for).

It is not true that "there are two types of Hebrew". The customary
practice is to include as few or as many vowel marks as the targeted
reader needs to disambiguate the content. This implies a contextual
continuum of content modes, ranging from no marks at all (e.g. in
notes to oneself) to all available marks (e.g. in content intended for
new users of Hebrew or for people with reading disabilties). Most
everyday content is somewhere in between. For example, newspaper
articles provide marks for unusual words and for foreign names once or
twice, then continue without marks after the context is established.
This is analogous to usage, which is also sensitive to audience and
context - but also analogous to the choice of font (e.g. the use of
Fraktur for historical content in German).

So: "Usage" could be misleading. If "content modes" is too broad, then
I would like to hear suggestions from others.

-- 
				Adam Reed
				areed2@calstatela.edu
				 
Context matters. Seldom does *anything* have only one cause.

On Wed, Jul 18, 2001 at 09:54:42PM -0400, Al Gilman wrote:
> At 08:49 PM 2001-07-18 , Wendy A Chisholm wrote:
> >Victor,
> >
> >As I understand the specific issue that Lisa raises, there are two types of 
> >Hebrew, one with vowel marks and one without.  If someone is presented 
> >Hebrew without vowel marks, they might not be able to read it (either 
> >through a processing disability of their own or their user 
> >agent's).  Therefore, we want to suggest using Hebrew with vowel marks.
> >
> >One way to generalize this is to say
> >"use fonts, languages, API's, and protocols..."
> >or
> >"use character encodings, languages, API's, and protocols..."
> >or
> >"use character sets, languages, API's, and protocols..."
> >
> 
> AG::
> 
> Yes, "content mode" is too broad.  But all the alternatives you raise have
> good
> meanings that aren't what we are after.
> 
> I am afraid that we may have to fall back on the general term 'usage' here.
>  In
> other words, say "Follow usage that is compatible with assitive tranforms.
> For
> example spell Arabic and Hebrew out with explicit vowel marks, to ensure
> Text-to-Speech compatibility."  
> 
> The use of the term 'usage' gets the reader thinking in terms of how you use
> the features of the natural language.  That is pretty much what we are talking
> about when the question is spelling.  What characters you use to indicate a
> word is a natural language concern, above the level of character encodings,
> and
> not implied by just the selection of language in cases such as this where the
> langauge is subject to the variation in spelling usage."
> 
> It is easy to make clear in the form of a heuristic slogan, "Write it down;
> spell it out."  But that catches the direction, but not the extent of the
> imperative.
> 
> Al
> 
> >This is based on my understanding of these documents:
> ><http://www.w3.org/International/O-charset.html>http://www.w3.org/Internat
> ional/O-charset.html
> ><http://www.w3.org/International/O-fonts.html>http://www.w3.org/Internatio
> nal/O-fonts.html
> ><http://www.w3.org/International/O-MissCharGlyph>http://www.w3.org/Interna
> tional/O-MissCharGlyph
> ><http://www.w3.org/International/O-HTML-tags.html>http://www.w3.org/Intern
> ational/O-HTML-tags.html
> >
> >"content mode" seems too general a term and one that I do not see used in 
> >the Internationalization documentation on the W3C site. 
> ><http://www.w3.org/International/>http://www.w3.org/International/
> >
> >I also think that we might be able to include this as an example of 
> >selecting which (markup) language to use - assuming that with SVG and 
> >future support of styling languages one could select or create a Hebrew 
> >font with vowel marks over one without.
> >
> >Regardless, this is a good example to add as part of the rationalization.
> >
> >Thanks,
> >--wendy
> >
> >
> >At 08:59 PM 5/18/01 , Adam Victor Reed wrote:
> >>I suggested the addition of content modes to Gudeline 4.1 as a
> >>possible way of dealing with the vowel mark problem in Hebrew and
> >>Arabic, which was brought to our attention by Lisa Seeman (vowel marks
> >>are required to support screen reading in user agents, and for
> >>accessibility to people with limited reading ability.) If there
> >>is no objection, I would like to see Gudeline 4.1 updated as follows:
> >>
> >>4.1 Choose content modes, languages, API's, and protocols that support
> >>the use of these guidelines.
> >>         Content modes (e.g. Hebrew with and without vowel marks,)
> >>         markup languages, multimedia formats, software interface
> >>         standards, etc., vary in their support of accessibility. When
> >>         choosing which technologies and content modes to use, consider
> >>         how easy it is apply these guidelines. Where feasible, favor
> >>         content modes and technologies that:
> >>         * support assistive technology in user agents;
> >>         * permit equivalents to be associated with or synchronized
> >>           with auditory, graphical, and multimedia content;
> >>         * allow the logical structure of the content to be defined
> >>           independently of presentation;
> >>         * support device-independence;
> >>         * are documented in published specifications and can be
> >>           implemented by user agent and assistive technology
> >>           developers.
> >>--
> >>                                 Adam Reed
> >>                                 areed2@calstatela.edu
> >>
> >>Context matters. Seldom does *anything* have only one cause.
> >
> >--
> >wendy a chisholm
> >world wide web consortium
> >web accessibility initiative
> >seattle, wa usa
> >tel: +1 206.706.5263
> >/--
> >

Received on Monday, 23 July 2001 15:17:43 UTC