[sw-l] Are We Going in the Wrong Direction?

[Sandy Fleming]

Val wrote:

> I think a lot of you may have lost the idea of what the IMWA is....It
> is not meant for small computers or for tiny little software programs.

Thanks, Val, that comes as a breath of fresh air!

But it got me thinking about what other things we perhaps have to check to
see if we're using them inappropriately, and I've found that this may strike
at the heart of our "software problem", ie the fact that we are having to
wait a long time for programmers to produce good editors and sign
processors.

I'd like to look at some examples of things that I think some of us may have
taken for granted when there are better ways of doing things. The result of
this was surprising to me: it seems to show that our software problems are
caused not so much by the difficulty of writing SW software as the fact that
we're using some of our best ideas inappropriately. This has enabled me to
address the "software problem" on two levels: one being that with a fresh
look at sign storage and display we could make software a lot easier to
write; the other being that if we could take it a little further we could
even use existing programs (such as Microsoft Word, or even more
programmer-friendly, OpenOffice) for SignWriting.

Here are some of the areas where I think misuse of concepts could hold us
back (other than the IMWA, which Val has already addressed)...

Lanes
=====

Is having special features and special SWML elements for expressing lanes an
unnecessary complication for programmers?

It would be a lot better if we could simply select and move groups of
symbols around together (rather than just one symbol at a time). We could
then dispense with SWML support for lanes and leave it up to the user to
position the sign in the lane he wants - or indeed exactly where he wants in
the column. A programmer optionally could provide a way of allowing the user
to snap signs into the "standard" lanes, but I think storing the lane
information should be in the document introduces problems which I'll explain
below.

Signs
=====

An unquestioned aspect of the software we have at the moment is that the
software whould store symbols grouped in signs. But is this grouping
necessary for storing SignWriting texts in a document?

It would be simpler to introduce a "space" character or gif to the IMWA -
like any other punctuation mark but blank - and express a SW document as a
string of symbols, including their coordinates (I would suggest relative
coordinates rather than absolute) and let the divisions between signs be
indicated simply by the presence of a space.

At this point you may begin to see the direction I'm heading: I'm asking,
"What if we steered things so that stored SW text behaved more like the text
files (strings of characters) used by software for processing oral-language
texts? Then it might become possible to use oral-language processors and
algorithms to handle SW texts, instead of having to write our own software
from sxratch, as we're doing at the moment."

This also shows what's bad about storing lane information in the document:
it makes it harder to treat our SW texts in the same way as oral-language
texts, making it harder to use existing oral-language software for SW.

SWML
====

SWML is fine as a dictionary storage format (something like the way
oral-language dictionaries do well with their own flavours of XML), but is
it really suitable for storing documentation?

The way SWML has XML elements for storing both signs and symbols is
analogous to an oral-language text system that has XML elements for storing
words and characters individually. Modern word processors do often store
text as XML but the XML doesn't go down to word or character level. Although
XML storage thus causes the document files to be much larger, with SWML the
bloat for large documents would be really enormous.

The structure of SWML also excludes the possibility of storing SW texts in
anything resembling the strings of characters normally used for
oral-language texts, and so makes the use of oral-language software for
SignWriting impossible.

So what should we be doing?
===========================

Here's a possibility.

Supposing we had SW symbols created as fonts, preferably unicode, or failing
that, as a specially-created SW symbol font. Failing that, the gifs/pngs
from a subset of the IMWA itself might have to do, but for the sake of the
example, let's imagine we have a font. This font includes a "space"
character as described above, so that signs can be indicated simply by using
a space or other punctuation mark to separate sequences of symbols, much as
space and punctuation characters separate words in oral-language texts.

This would mean we could simply use any oral-language word processor or text
editor to create SW documents.... except for one thing! Which is that we
also have to be able to indicate where exactly each symbol is to be placed
in two dimensions. I think that this can be arranged, though it may involve
some modifications to existing word processors and text editors, just as
they once had to be modified to cope with right-to-left and vertical texts.

We might be able to persuade the writers of the software to implement a
facility to allow us to place characters (ie symbols) anywhere - after all,
it would be an interesting enhancement for oral-language text features as
well. If we're even luckier there may be some program that already allows us
to do this (LaTeX, for example?). If not, then instead of our programmers
having to write sign processors from scratch, they could obtain open source
word processors and adapt them themselves.

I've thought this through in more detail - the use of vertical/horizontal
columns and relative positioning of symbols, and a standard ordering for
symbol sequences. But perhaps this is a good place to stop because that gets
a bit technical and I'm hoping non-programmers will read this too!

I appreciate that it might be up to me to write these things (proof of the
pudding, etc) if no-one else cares to, but I thought it was worth saying all
this because I think any programmer working on a SW project should be aware
of these issues, so that they don't waste lots of time programming things
from scratch when there's something available that could be made to do it
already.

Sandy