SWML
Stuart Thiessen
sw at PASSITONSERVICES.ORG
Tue Jun 26 04:19:19 UTC 2007
Hi! Actually, there are other alternatives to a web-based approach.
You can use programming languages such as Perl, Python, or Java to
create programs that can run on multiple platforms and that do not
require the web. For example, their is an excellent opensource sign
language research tool called ELAN which allows researchers to
analyze video clips of sign languages and make various annotations of
the video clips for their research. It is written in Java and is
available for Windows, Mac, and Linux. Certainly, there are pros and
cons and give and take that happens when you program so that it works
on multiple platforms. But Web-based programming as the only cross-
platform programming approach is a common misconception. It is
certainly one of the options which is what Steve picked for his
approach. I'm sure whatever you create will work well on Windows, but
it will be useless to those of us not on that platform. WIth such a
diverse group that we are, I personally tend to encourage programming
approaches that focus on being available on multiple platforms so
that everyone can benefit without having to purchase another computer
just to benefit from a program. I just think that's a wiser use of
resources and it doesn't take any extra effort other than learning a
programming language that can actually work on multiple platforms.
All of the languages I have mentioned are free, so it will cost
nothing to install their IDE's and work with them.
If you decide to stick with VB, I suggest you explore Mono. That is
an open source way to run .NET programs. That might be one way to
make it available for other platforms. But I have never done that
myself, so I am not sure how that works.
Thanks,
Stuart
On 25 Jun 2007, at 22:15, Jonathan wrote:
> Hi Stuart,
> My current plans for my program are Windows only. But if there
> is a way down the road to run it or port it to Linux or even
> Macintosh, then I might look into it. The only way to make work
> well on every platform is for it to be on the web like SignPuddle.
> But SignPuddle already exists and if my program was web based, many
> people who don't have access or can't be connected very long
> couldn't make very much use of it. There are advantages and
> disadvantages to each programming style.
>
> Jonathan
>
> Stuart Thiessen wrote:
>> Having a VB program would be interesting, but it would not be
>> accessible to those of us on other platforms such as Macintosh or
>> Linux, would it?
>>
>> Thanks,
>>
>> Stuart
>>
>> On Jun 12, 2007, at 14:00, Jonathan wrote:
>>
>>> Hi Steve,
>>>
>>> Steve Slevinski wrote:
>>>> 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.
>>>>
>>>> One question... Should we have 2 different formats? One for
>>>> dictionaries and another for documents? It might make sense to
>>>> be able to embed the document markup inside of the dictionary
>>>> markup, since signs can now have documents attached.
>>> I would prefer 2 different formats. This would make it easier to
>>> the end user to know if they are dealing with a dictionary
>>> listing or a document. But we could make the internal markup
>>> quite similar.
>>>>
>>>> I need to improve the export feature in SP1.5. It should
>>>> export in a variety of formats.
>>>>
>>>> SBML is for importing into SignBank and below is my rational for
>>>> using the comma delimited strings.
>>>>
>>>> Image Importing
>>>> ---------------------
>>>> SignBank uses images in the FileMaker database for the signs.
>>>> However, there is no way to import images into SignBank using XML.
>>> Including images in XML isn't very common. But I did find some
>>> articles that explain how. The image is converted to base64 and
>>> stored in the XML. SignBank can't do that so it made sense to
>>> just keep the build string together since that's what SignBank
>>> needed to get the picture in the first place.
>>>> The round about solution we found was that FileMaker can grab an
>>>> image off of the internet. So SBML includes the build string
>>>> and SignBank opens a web image with the build string as a query
>>>> value.
>>>>
>>>> Example build string:
>>>> 01-01-001-01-01-01,5,5,02-01-001-01-01-01,70,15
>>>>
>>>> Web image:
>>>> http://www.signbank.org/signpuddle1.5/image.php?
>>>> build=01-01-001-01-01-01,5,5,02-01-001-01-01-01,70,15
>>>>
>>>> SignSpelling Sequences and sorting
>>>> ---------------------------------------------
>>>> I've been sort the SignSpelling Sequences as strings.
>>>>
>>>> 01-01-001-01-01-01,01-01-001-01-01-08,
>>>> 01-01-001-01-01-01,02-01-001-01-01-08,
>>>> 01-01-001-01-01-01,06-01-001-01-01-01,
>>>>
>>>> Since SBML already used the comma delimited build string, I
>>>> didn't see a problem with throwing in the sequence as a comma
>>>> delimited string as well.
>>>>
>>>> I'm not sure how SignBank is storing the sequence in the
>>>> database, but Todd Duell was able to use SBML as I created it so
>>>> I left it alone.
>>> Thanks for explaining.
>>>>
>>>> Just a bit of background,
>>>> -Steve
>>>>
>>>> Jonathan wrote:
>>>>> Hi Steve,
>>>>>
>>>>> Steve Slevinski wrote:
>>>>>> Hi Jonathan,
>>>>>>
>>>>>> The gloss should be a tag and not an attribute. It looks like
>>>>>> your example comes from the SignPuddle 1.0 export, which does
>>>>>> not follow the DTD. That's a defect.
>>>>>> http://www.signbank.org/signpuddle/swml/swml-s.dtd
>>>>>>
>>>>>> Jonathan wrote:
>>>>>>> I image that the "gloss" tag was meant so that there could be
>>>>>>> several glosses per sign. Is this right? If it is so then the
>>>>>>> "symbol" tags should be withing the "gloss" tag or else we
>>>>>>> won't know which "symbol" tag belongs to which "gloss" tag.
>>>>>>> It isn't enough that the "gloss" tag come first.
>>>>>>
>>>>>> Each sign can have multiple glosses and multiple symbols. The
>>>>>> glosses and symbols are not directly related. The symbols
>>>>>> make up the sign. And the gloss describes the sign in English
>>>>>> words.
>>>>>>
>>>>>> For example, the sign for the ASL number one has a single
>>>>>> symbol, but multiple glosses.
>>>>>> <sign>
>>>>>> <gloss>one</gloss>
>>>>>> <gloss>1</gloss>
>>>>>> <gloss>uno</gloss>
>>>>>> <symbol x="1" y="1">01-01-001-01-01-01</symbol>
>>>>>> </sign>
>>>>>>
>>>>> I had misunderstood the reason for the gloss tag. Thank you
>>>>> for the explanation. It makes sense to me know.
>>>>>>
>>>>>>> My other comment about SBML which I realized was made
>>>>>>> especially for SignBank which I am sure works just fine. But
>>>>>>> SBML uses comma separated values. Which are fine, I use them
>>>>>>> all them time. But I feel that they are out of context in an
>>>>>>> XML file. As is I can load the SBML into objects or a
>>>>>>> dataset but I still have to parse the build and the sequence
>>>>>>> to get to the information. But if each comma separated value
>>>>>>> has it's own tag, it will load just as fast into an object or
>>>>>>> dataset and I don't have to do any parsing to get at the
>>>>>>> information. So for a SignWriting exchange format, I
>>>>>>> strongly suggest staying away from comma delimited strings.
>>>>>>>
>>>>>> Hmm. I can understand your feeling. I'm not sure which style
>>>>>> I'm going to use for STML. I should probably use the verbose
>>>>>> tag style, but I've never had a case where I was glad I chose
>>>>>> the verbose style over the build format for SWML-S.
>>>>> Is this because you find it easier working with comma delimited
>>>>> structures than objects? I understand your point. Especially
>>>>> if you don't have an easy way to load the XML into the object
>>>>> or dataset.
>>>>>
>>>>> This what I have figured out about XML so far.
>>>>>
>>>>> The free IDE for Visual Basic, Microsoft Visual Basic 2005
>>>>> Express Edition, has a command line program that will analyze
>>>>> an XML file and determine it's schema. I was playing around
>>>>> with the SBML format a while ago and using extensive search and
>>>>> replace, converted it to an all tag format. See attached file
>>>>> sbml.xml
>>>>>
>>>>> I didn't split up the detail though. Then I ran it through XML
>>>>> Schema Definition Tool to create the schema. See attached file
>>>>> sbml.xsd
>>>>>
>>>>> Then I ran the schema specifying that I wanted it to give me a
>>>>> dataset in VB. See attached file sbml.vb
>>>>> I used the System.Data.DataSet.ReadXml method.
>>>>>
>>>>> I managed to import the whole ASL dictionary into my program
>>>>> this way.
>>>>>
>>>>> It can also do classes for objects.
>>>>> I did one for you. See attached file sbml-object.vb
>>>>> Then use the
>>>>> System.Xml.Serialization.XmlSerializer.Deserializer method to
>>>>> read the XML file.
>>>>>
>>>>> The code to load the SBML into the object is
>>>>> Dim mySbml As sbml
>>>>> ' Construct an instance of the XmlSerializer with the type
>>>>> ' of object that is being deserialized.
>>>>> Dim mySerializer As Xml.Serialization.XmlSerializer =
>>>>> New Xml.Serialization.XmlSerializer(GetType(sbml))
>>>>> ' To read the file, create a FileStream.
>>>>> Dim myFileStream As IO.FileStream = _
>>>>> New IO.FileStream("E:\Mis Documentos\Jonathan\Visual
>>>>> Studio 2005\Projects\Handwriting\IMWA\bin\Debug\sbmlnew.xml",
>>>>> IO.FileMode.Open)
>>>>> ' Call the Deserialize method and cast to the object type.
>>>>> mySbml = CType( _
>>>>> mySerializer.Deserialize(myFileStream), sbml)
>>>>>
>>>>> The results of the object look like the attached file "Loaded
>>>>> SBML object.png". Then you can use code to work with the
>>>>> object just as you would any other object.
>>>>>
>>>>> It is just as easy to go the other way too. Object or Dataset
>>>>> to SBML.
>>>>>
>>>>> With the xsd.exe utility, you can also choose from CS (C#,
>>>>> which is the default), VB (Visual Basic), JS (JScript), or VJS
>>>>> (Visual J#).
>>>>>
>>>>> Jonathan
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listserv.linguistlist.org/pipermail/sw-l/attachments/20070625/cf18362d/attachment.htm>
More information about the Sw-l
mailing list