--- In xpl-dev@y..., "Richard Anthony Hein" <935551@i...> wrote:
Hi everyone,
I joined this list yesterday, and have been reading the archive. I
plan on
being a contributer, by using my database development experience
(Access,
SQL Server), and VB to the table. I have been heavily into XML and
related
technologies since around November 1999, read the specs on the DOM
level 1
and 2, XML, XSL (wow it's long!), and am just about done XPath at this
point. Oh yeah, also XSLT and XML Schema and SOAP. However, I
haven't been
able to really put this all to use yet. I shall.
Now, I want to ask if anyone has seen the work on XMLScript? You can
see
what has been done at www.xmlscript.org.
I think that what we want to do here is bigger than what XMLScript
encapsulates ... however, that doesn't mean we can't use XMLScript as
a base
for what we want to do ... make a new fully enabled programming
language
specific to XML. XMLScript COULD be to XPL what JavaScript is to
Java, and
VBScript is to VB. Or, perhaps XMLScript will someday become XPL.
Who
knows; but it would be foolish for us not to consider this work, as
it's
well ahead of XPL at this point.
In the meantime, I will say this ... the Holy Grail of XML
programming would
be the ability to write in any language which is defined by an XML
schema
(NOT DTD's!), and be able to transform that into another language. I
am
talking about computer language as well as human language. However,
I am
not saying let's work on human language translation ... but this
work, if we
all agree that this cross-language ability is important, could be
useful in
the future. Things we learn from translating across programming
languages
could be very useful in the future, when applied to translating human
languages.
So, is this a part of XPL's intention or not? Is the ability to
translate
across any programming language that has a well-formed and valid
schema
going to be part of XPL? If so, let's put that in a specification.
We have the work of things like SOAP which well be totally helpful to
us.
SOAP shows us how we can wrap messages (think of them as method
calls) in
XML, and use that wrapper to communicate with any component that is
SOAP
enabled. This is amazing stuff, and practically makes Java nothing
more
than a language now, as Java's cross-platform benefits are really
irrelevant
now. We can use this idea to make translation happen.
How? Well, if we wrap a C++ component/function/method in SOAP like
XML
syntax, and name it according to some standard convention that we
realize in
XPL, then we can map it to a VB component/function/method that does
the same
thing. In this way, the translation is not based on any real
schema ... we
simply have a source of information that can find the same component
in any
language. This is the easy way, and depends on having the same things
written many times, in many languages. It's not really what we want
to do,
but we can use it to our advantage.
How? :) We can use that method when we run into trouble
translating ... for
instance, someone pointed out:
Java's dynamic class binding will not translate to
C++ static binding, without the creation of some kind of
object tag system for the C++. This is a problem.
We could use a search type method to find components that do the same
thing
that the class in Java does, but in C++, using SOAP and SDL to find
it, and
then use that code to enable translation. If we can somehow make it
possible to UPDATE the schema (using our search results) then we may
be able
to "evolve" the schema to meet these problems, so in the future, the
translating powers of the XPL can use that schema update to know what
to do.
This is just an idea, and is probably full of holes, so go ahead and
point
them out or fill them in!
Richard A. Hein
dbSoft
--- End forwarded message ---
|
