Steve said:
I recall a few months ago coming across an article allowing for encoding
(or converting?) xml and html documents into sign language
This seems slightly dubious -- sign language is a rendering technique,
not a document format.
Although there is some use for "a document format that represents sign"
(publishers of illustrated sign-targetted books could certainly use it)
then that's a pretty trivial exercise in writing an XML schema.
Elements within this schema could represent the various signs (fully,
and accurately, with all their subtleties) and could also model most of
the mapping between the world's various sign vocabularies. A good idea,
with great benefit to a small number of people.
A more generally useful technique would be a "sign browser". Take a
document, _any_ document, and render it using sign language. In effect
it's a translation tool from text to sign. This is of less general use
(using sign is no indication that you can't read for yourself!) but
it's more widely applicable. Sign users can feed any content they like
into it, just like a speech browser, without requiring any
sign-specific markup on the overall document.
If you want a document to "render in sign" no matter who reads it, then
that needs some embedded document content more than just a single
<meta> on the top (embedded XML via namespacing might do the job).
If you want to make general documents "sign-browser compatible" then
some such browsers might indeed want to see a "sign capable" <meta> on
the document, but that's a badly thought-through feature. Why can't
they just accept any well-formed HTML ?
If "rendering text as sign" is too hard (and it _is_ hard), then it
might well be useful to embed "sign ruby" throughout the document text
and to hint at the intended meaning of homonyms etc. Again though, this
is spread throughout the text, not just a per-document <meta>