<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<br>
Sandy Fleming wrote:
<blockquote cite="mid1180860571.7559.24.camel@localhost.localdomain"
type="cite">
<pre wrap="">Hi Steve, Jonathan,
On Wed, 2007-05-30 at 11:50 -0400, Steve Slevinski wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi Jonathan,
You are right that we need a general format for importing / exporting
between SignWriting applications. I'd say that we should clean up
SWML-S. I was also working on a SignPuddle Markup Language that I
used internally to import the 1.0 dictionaries into 1.5. I never
finalized the DTD.
</pre>
</blockquote>
<pre wrap=""><!---->
I have a problem with SWML, which is that it doesn't describe sign
structure at all. It acts as a container for SignWriting rather than a
description of the structure of SignWriting signs (or "characters" as I
tend to call entire written signs these days).
If programs didn't need to know about sign structure, then it wouldn't
matter, but I think they do need to know about it.
For a keyboarding program, for example, the software needs to know which
channel of communication (face, active hand, passive hand &c) it's
typing in: the keyboard doesn't have enough keys to type every symbol so
the program needs this structural context.
The software also needs to know such things as which movements belong to
which channel, so that it can flip, slide or anchor between the active
and passive hand/arm configurations, replace one head with another and
so on.
I don't see how you can give the user these sort of features with SWML.
I also don't think programmers should get too hung up on formats! The
core of a program should respond to a series of procedure or function
calls and respond with a series of calls. Nothing about the formats
should be written into the program: instead there should be input and
output packages that interface between the program's calls and the
input/output formats, so that different formats can be handled just by
writing the appropriate package for each one.
</pre>
</blockquote>
I agree that SWML can't be the base structure for our programs. It
wasn't intended and never will be able to adapt itself to our procedure
and requirements to draw, or create documents. It is just a sharing
format to share the results between programs. Maybe a discussion about
an interchange format would be more productive when we have all
finished the first version of our programs.<br>
<blockquote cite="mid1180860571.7559.24.camel@localhost.localdomain"
type="cite">
<pre wrap="">
As for whether we need two different formats for text and dictionaries,
well, in text I suppose we need to have styles and suchlike, which we
wouldn't want in dictionaries. In dictionaries we'd need semantic
definitions, which we wouldn't want in the text. I suppose we could just
leave these out as appropriate, but then again, having a dictionary in
the same format as text could hamper dictionary lookup: a dictionary
stored as a database would make more sense whereas a text stored as a
database would make less sense (perhaps?).
</pre>
</blockquote>
You're right. You wouldn't want more than one document per file but
would want more than on sign per dictionnary file. And you wouldn't
want a user to try to import a dictionary into a document or a document
into a dicctionary entry either.<br>
<br>
Jonathan<br>
<blockquote cite="mid1180860571.7559.24.camel@localhost.localdomain"
type="cite">
<pre wrap="">
Sandy</pre>
</blockquote>
</body>
</html>