Thank you Charles for your reply.
My disappointement was acually a little more than 'slight'.
LREC stands for 'Language Resources Evaluation Conference' - LANGUAGE
RESOURCES! and not one paper or poster tackled the issue of WRITING sign
language. The focus is so heavy on the technology side of creating
machines that can do and read sign language - that the very basic and
human capacity for WRITING as a language resource is overlooked.
Maria

> HamNoSys from my understanding, is like Stokoe, it is a linear exposition
> of Sign Languages, not based on their actual appearance in space, which
> Sign Writing does.  The only way to change minds and hearts is to show
> TISLR, as we are doing in October, with poster sessions and other
> methodologies, actual linguistic research using both databases and
> exposition. 
>
> We are dealing with inertia here, and a real culture of denial that a
> writing system can actually work.  It will take your groundbreaking work
> and the work of users like Fernando Capovilla in Brazil to turn that
> around, and that with so many piles of literature that it cannot be
> ignored.
>
> Publish, publish, publish, the overwhelming evidence will change the
> culture.
>
> Charles Butler Neto
> ASL and Libras user.
>
>  
>
>
>
> ________________________________
> From: MARIA AZZOPARDI <[log in to unmask]>
> To: [log in to unmask]
> Sent: Wed, May 26, 2010 4:45:08 PM
> Subject: Re: Data exchange with SignPuddle Markup Language
>
> Dear Steve, Val and all the list,
> I attended the LREC 2010 and I must say I was slightly disappointed at the
> very low use of SignWriting in Computer Sign Language linguists. There
> were some researchers that told me they considered SignWriting, but opted
> for HanNoSys. It would be ideal if SignWriting were used, I thought, but I
> probably can't understand the technicalities, as computers are not my
> area.
> Could you explain why the situation is so.
> Thank you very much,
> Maria
>
>> Hi Bill,
>>
>> In SignPuddle Markup Language, there are 3 main parts of information:
>> terms, text, and source.  SignWriting can be used in each.  The voice
>> language items are defined the same as sign language items.
>>
>> However, by convention, I will be using voice language items differently
>> than sign language items.
>>
>> The voice language items will use UTF-8.  This will be straight
>> character data, so I'm wrapping the entires as a CDATA block to avoid
>> parsing.
>>
>> The sign language items will use BSW as hexadecimal.  I still need to
>> decide if terms can be one than one sign.  This will determine if terms
>> are edited with SignMaker or SignText.  I need to decide the same for
>> the source: one sign only, or more than one sign.
>>
>> For the ultimate in flexibility, I could have the sign language items
>> use UTF-8; the same as the voice language sections.  I would need to
>> encode the Binary SignWriting using the UTF-8 I propose with the plane 4
>> solution.  This way, we could mix sign language with HTML markup and
>> other spoken languages.  However, this encoding is not approved by the
>> Unicode consortium so it may be considered bad manners to start using
>> plane 4 without their approval.
>>
>> Either way I go, I will not need to update the SPML DTD definition.  You
>> can see that I am not limiting the terms, text, or source.
>> http://www.signpuddle.net/spml.dtd
>>
>> Here's an abbreviated definition
>> <!ELEMENT spml (entry+)>
>> <!ELEMENT entry (item+)>
>> <!ELEMENT item (term*,text?,src?)>
>> <!ELEMENT term (#PCDATA)>
>> <!ELEMENT text (#PCDATA)>
>> <!ELEMENT src (#PCDATA)>
>>
>> + one or more
>> * zero or more
>> ? zero or one
>>
>> Regards,
>> -Steve
>>
>>