Contribute An Article
If you have a point you'd like to make about the Smalltalk and XML that would contribute to others please write an article and we'll consider posting it here. Editor
I think it's important that Smalltalk has a "XML" ASCII standard for storing BOTH
"Smalltalk source code" and "Smalltalk object instances".
Interoperatability is becoming very important and being able to share
object instances with other languages and systems would revolutionize the
Smalltalk usage in the real world.
Smalltalk MT already stores their source code in XML. While I'm not saying
that their "project" xml format is the one to pick it's very flexible. An
example
of Smalltalk source code stored in XML from Smalltalk MT is included below.
Using XML to store Smalltalk source code, as James A Robertson of Cincom
pointed out while at the Vancouver Smalltalk Users Group recently, would
enable the different versions of Smalltalk to interoperate with each other
at the level of reading and writing source code. Extensions are TRIVIAL and
the other vendors don't have to support them if they don't want to. Also
project management software (Envy, Team/V type tools) can add their own
tags as required.
Having a binary standard is fine, but it wouldn't be as flexible as XML
(unless we make it so). The Advantages of interoperatbility gained with
XML, in many situations, outway the few limitations: XML tends to be
"verbose", it requires a "parser" and "validator" (optional), and it may
have extra processing overhead. These disadvantages are insignificant when
considering the Web's movement to XML. If you follow and of the progress at
W3.org/XML and
apache.org
you'll see that soon the Web
servers will be serving up XHTML and becoming "XML" servers. XML is
becoming one of the main interoperatability standards.
One of the reasons for XML becoming a standard is that it can represent
"hierarchical" and "network data structures" which makes it trivial to
represent "object instance graphs/networks". XML is also "language and
vendor neutral". XML is very similar to HTML and there are a lot of people
who are familar with and who know HTML - which is almost a mandate to
include full XML support in all versions of Smalltalk.
A XML object instance format would enable ALL versions of Smalltalk, Java,
C++, Eiffle, etc... to store object instances and more importantly retrieve
them EVEN if they were written by another system. Image an "XML BOSS" or
"XML ObjectFiler". And with the source code also stored in a
"XMLSmalltalkObjectInstances" file you've got the instances with their
class definitions! Load and go! Party on.
If we want web masters around the world to jump on the Smalltalk bandwagon
and use Smalltalk for their web site applications and page generation then
we must provide tools that they are familar with (
W3.org/XML,
modules.apache.org,
modules.apache.org/reference,
apache.org,
perl.apache.org,
php.apache.org,
etc...). PERL, PHP, and lowly unix shell
scripting have special places with web page design. What will it take for
Smalltalk to gain a similar warm spot in hearts and minds of webmasters everywhere?.
One consequence of this proposal is that there needs to be an
Open Source
and standardized XML object class library for ALL versions of Smalltalk.
How can you help with this effort? Porting and debugging the
Indelv
Smalltalk XML Open Source Code
to as many Smalltalk systems as possible would be a great start. We also need to define the
XML Document Type Definition for Smalltalk Object Instances and Source Code.
While it is true that a "major disadvantage" of XML is that it's "text"
based as opposed to "binary" based the "impact" of this "major
disadvantage" is actually determined by your need. If you need a "compact
and fast to export/reload" format then maybe a binary format is better for
that usage.
It can also be said that a "major advantage" of XML is that it's "text"
based. If you need "transportability, industry compatibility, human
readability, open system specification, widely adopted standard,
readability in 21 or more years (engineering, aerospace, accounting, legal
fields, etc...), interchangability between systems, and possibly the most
important reason is that the WEB is moving to XML" than maybe XML is for
you. Oh ya, don't forget "extensible"!
From personal experience on many projects having a "human readable" and
"human writable" format for storing Object instances and source code will
make a tremendous difference.
Certainly having Smalltalk source code in "Smalltalk chunk format" has
saved many projects from disaster (including the earlest Smalltalk systems
such as Smalltalk 72).
XML can be compressed to very compact formats. There are now a number of
XML specific compression programs that get better compression that zip (see
the free XML tools link below and
XMLZip
). In a sense they are
converting the text format into a "compressed binary format". There is more
than one way to meet the "compact" requirements that some applications
have...
A "object serializer" can be designed and implemented with "multiple
backends" for different storage formats such as "compact binary", "XML",
"BOSS (VisualWorks)", "ObjectFiler (VSE)", etc... The front end of an
object serializer (graph walking to determine what objects to export for
example) is usually the more complex part anyway so it should be isolated
from the specific format that it can read and write. You could even
configure it to read in a "binary" format and write out a "XML" format or
vice versa.
A significant reason to use XML is that the WEB is moving in that
direction. It would be foolish to not have the ability for Smalltalk to
read in Objects that were written in XML by other systems like Java, C,
Perl, PHP, C++, Python, Eiffel, Apache, Linux, Microsoft Apps, etc...
Another issue seperate from creating a "Smalltalk specific" XML format
"optimized" for Smalltalk is the ability of Smalltalk to deal with other
systems "XML object instance" formats in a "flexible and easy" manner. This
would allow Applications written in Smalltalk to interoperate with
Applications written in other languages.
The bottom line is that it comes down to what you value and what
requirements your application users require. As noted earlier having a
binary and XML Object instance and source code format are not incompatible
design notions; in fact they could be implemented in the same Smalltalk
library of objects if the design accounts for this flexibility. Thus both
sets of appearantly "contradicting" values and requirements can be met.
SMIX
Well wonders never cease to amaze me. Masashi Umezawa,
umezawa@tyo.otc.ogis-ri.co.jp, has defined "SMalltalk Interchange Format in XML", or "SMIX", as part of his Dandylion project. You can check it out at his web site Dandylion SMIX. It seems like it needs some more work or documentation, but it could be a good starting point.
SMIX as it is seems a bit to cluttered and wordy to me. This is a general problem with XML and many XML DTDs in the first place so the tags need to be as short as possible and still make sense. What do you think?
-- Peter
Excellent XML Examples Ariba's cXML is a very clear and clean example plus excelent explaination of how XML servers will become more popular than HTML servers). Download Ariba's cXML (zipped PDF).
Financial Product Markup Language a.k.a. FpML
XML Object Storage Related Standards
"If you want an XML marshalling for objects, it'd be great to be
compatible with either the WDDX standard, or the SOAP standard, as
much as possible. Unfortunately, both seem to have big backers (SOAP
from M$, and WDDX from Allaire), and are incompatible. SOAP seems to
have derived from the XML-RPC camp, which also has more visibility."
-- Randal L. Schwartz Simple Object Access Protocol (SOAP) Web Distributed Data Exchange (WDDX)
While it is important to consider other standards especially if they are popular, it's also important to make sure that the XML Smalltalk format doesn't compromise any smalltalk related requirements. XML is great for the exact reason that it's extensible. Lets consider the reqirements for a Smalltalk XML format and then see if SOAP and WDDX provide the solution or not.
