| 1) |
XML data encapsulation within XML itself-- XML is used
as a special means of cross-platform data exchange and RPC via SOAP. It
therefore makes sense that the data should be encapsulated in XML itself so
that the data and the means of encapsulation can be secured, accessed and
transported as an unit within a logical tier. Plus, it also makes sense to
secure the XML data within the same tier without a reliance on other
technologies: Java and CORBA, C# and .NET, VB or C++ and COM. All of these
existing methods enforce that the XML clients (the Java and CORBA, et. al.)
must know the details of the XML data and manipulate it directly. On
theoretical grounds this undermines the integrity of the XML data as is since
it does not stand alone. On practical grounds this means that the
cross-platform benefit of transporting the XML data and its encapsulating XML
objects is not there at all. In short, Superx++ objects package XML natively. Why is
this so? because Superx++ objects are also XML. |
| 2) |
A neat benefit also of the XML encapsulation that Superx++
offers is that the XML clients can remain unchanged. This is because they will
be invoking Superx++ programs which are also XML. So nothing on the XML client side
needs to change. |
| 3) |
The automatic benefit that you get from Superx++ use is
that it allows XML data to be adaptive! This is very important in the dynamic
systems we have today and also for research in evolutionary systems. This is
possible because the Superx++ objects (which are XML) provide the programmatic logic
to modify the appearance of the XML data to the XML client based on run-time
conditions. |
| 4) |
Let's face it: nowadays without Superx++, to manipulate XML
to any sufficient programmatic degree (with any sort of ease) you cannot use
the XML technologies, such as XSLT, XSLFO, XPATH, XQUERY, etc. These all
require a fair amount of complexity. Programmers have recognized this already
and that is why they turn to Java, .NET, and other language/frameworks to
manipulate XML data. Although this is a practical decision that seems logical,
it is not a step in the right direction. This is because it violates the
integrity of the XML data with invasive access and manipulation of non-XML
processes. A better model which is also practical is to use Superx++. Superx++ has a
syntax that is easy to learn and quite understandable. If you have used C, C++,
C#, Java or most other high level languages then Superx++ will not be hard to
master. This means that you can very quickly use Superx++ to access and manipulate
XML data in documents or fragments. And at the same time, while you are doing
this with Superx++ you are not violating the integrity of the XML data because that
data is kept within the XML layer, wrapped safely within the Superx++ objects.
Therefore, there is no reason why these Superx++ objects cannot be sent via HTTP to
some remote destination, as an unit and still preserve the encapsulation. |
| 5) |
By the way, there is another benefit of XML
encapsulation here, and that is that the Superx++ objects provide a context for the
XML data. A context is necessary in any system to make informational sense out
of data, which is inherently meaningless without a context. Imagine a system
with Java (or any other language excluding Superx++) and XML. That system taken as a
whole has a context because you can tell what the data is and what it is for
and how it is used. However, the current thought about transporting the XML
data to remote destinations is to take the XML data and ship it off via HTTP or
whatever. This move breaks the context. The destination can only really know
what the XML data means and what to do with it, if and only if the destination
is built with a knowledge of the source system. This is bad! The reasons why
this is bad are:
| i) |
It forces the context of the source system to remain
constant and in sync with the destination system. Therefore the company in
charge of the source system cannot modify the form that the XML data takes
without consulting the destination company. This means that the two companies
must agree and be in sync or the whole model breaks down. This is expensive in
terms of human resources, time, money and programmer expertise! |
| ii) |
If the source company is bought by another entity who
want to change the XML format of the data, then the destination company will
not be able to make sense of the data any longer. That is, there is no
long-term stability of the XML context! |
Some will object at this point and say that XML schemas could provide the
necessary context. I would agree to a certain point. The schemas can provide
lexical (not informational) definition of the XML format, but if the format
were to change then the schema must also change. This therefore brings us back
to square one: the source and the destination must BOTH make changes to adapt
to changes in the XML format.
The good thing about Superx++ encapsulation is that the entire Superx++ object can be
transported from the source to the destination as an unit. This object will
expose a public interface that is more stable and long-term than the tenuous
coincidental agreement on the XML format shown above between the source and
destination. This public interface is what the destination system (that is, the
XML clients on the destination which may be Java or other language programs)
will invoke to access the XML data via the secure interface of the Superx++ object.
Therefore if the source company wants to change the XML format then they can do
so while leaving the public interface the same and the impact on the
destination will be ZERO! This means that there is less expense for any change
on the source in terms of human resources, time, money and programmer
expertise!
|
| 6) |
Another benefit of Superx++ is that it allows object
oriented features that other popular languages do not. For example, class
redefinition. Class redefinition is the ability of a class to be redefined or
evolve dynamically at run-time. This evolution has the impact of changing the
behaviour of objects that were already instantiated, and of course the
subsequently instantiated objects take on the new form. This is useful for
modeling changes to entities in the real world. |
| 7) |
Superx++ also allows zero-cost XML serialization. By this I
mean that XML serialization is not implemented by means of the use of special
classes as is the case with the .NET languages or Java. Rather, it is founded
on a simple premise that sets Superx++ apart from these other languages. Superx++
maintains objects in memory as XML! Therefore an XML node is a Superx++ object and
a Superx++ object is an XML node. The ramifications of this are that serializing an
Superx++ object or object tree really means simply writing the data to a file.
Deserialization is also merely constructing an object out of the XML in a file,
which is also done in a single instruction. This makes the whole matter of XML
serialization easy for programmers to grasp and use and at the same time it
preserves the logical paradigm that we have established: i.e. Superx++ is truly XML
through and through! |
| 8) |
Superx++ allows XML data to be processed as Superx++ code and
Superx++ code can be manipulated as XML data. This allows a high degree of
flexibility in adaptive and evolutionary programming. This is important-- a lot
of research has and is being done in the realm of adaptive programming. Superx++
implements some useful features to allow this. |
