--- In xpl-dev@y..., Jonathan Burns <saski@w...> wrote:
Thanks, Garreth and Aly especially, for the affirmation.
I'll deal with Aly's ideas in a later post. Right now I
have to get these points down before I forget them.
1. The big issues are:
What can we do with XML documents?
and
What can we do to XML documents?
The first defines the area of XPL programming. For instance,
we can always parse them, and we can always bind operations
to elements, so that as a document tree is traversed in
parsing, and successively higher-level elements are recognized,
the operations are called. This is the generic scripting
language strategy, as employed with Perl, Tkl, etc. Very
significantly, there is XUL (pronounced so as to evoke
Sigourney Weaver in flame-red satin, i.e. "Zool"). XUL stands
for "eXtensible User-interface Language", and is being
used by the Mozilla open-source crowd to define much or all
the UI for the upcoming Mozilla beta release. This is something
I desperately want time to spend on. I haven't been into
the docs yet, but what I do know is, XUL elements are UI
widgets; mouse events must parse a XUL document, to discover
the element the mouse is focussed on; and Javascript
operations are bound to the events for each element.
Further, we know we can capture algorithms with xpl-basic
documents, such as we're now designing.
And there's more, my friends, where that came from! I'm
barely started with XPL functionalities.
Now here's what's wild. What we can generically do with
XML documents is exactly the same thing. Most XML types
exist to have operations (e.g. set font; make box; embed
text in Postscript, etc etc) bound to them.
I've got this book, XML Complete, Steve Holzner, McGraw-Hill.
Don't bother with it, except as an example to avoid. What
it will try to sell you on is that
for every DTD
for every application of that XML type
you're gonna have to hand-write a Java
program, containing all the app's operations
and implementing their binding to the elements
which trigger them
Which is nuts. Newbie though I be, even I can see that:
If you have a generic binding point element in some DTD,
say:
<binding>
<element in any other DTD>
<reference to operation>
</binding>
and if you include the second (target) DTD in a copy
of the first (application) DTD
then you have enough information about any target
element (its child elements, its basic types, heck,
the whole EBNF sub-grammar defined for it) to pass
references to the contents of an instance of the
element through to the operation.
Typically, the bundle of operations you'll call will
be the methods of a single class: the interface to
the execution methods you want the target document
to call when it is parsed.
So what we can do, in principle, is this:
Take one DTD for target.
Take another DTD to represent sets of operations.
There probably is one already. An XML document of
this type will represent a pure class interface,
exactly like a COM interface.
Make up a document which consists of <binding>
elements as above; with the <element> child of
each binding being from the target document, and
the <operation> child being from the interface
document.
These three documents in combination specify everything
that a hand-coded Java binding specifies. So, except for
the generic process of automating the provision of target
element content to the operations, who needs Java? Well,
okay, we might want to write the operations in Java, but
that's not even typical. Perl has bindings for every
language in the known universe - Javascript has been
mentioned, but there are class interfaces, C libraries,
hardware APIs, and so on and on. Perl has shown the way.
I'm being vague (it's 5:45 am here), but once I've got
it properly worked out, I think I can convince you of it.
Bottom line: XPL needs <operation>, <element> and <binding>
built in. Because then it can bind and parse, re-bind and
parse again, according to whatever control flow we care
to write into an XPL program - i.e. in xpl-basic!!!
As an example of what I mean: Here as target type we have
the DTD for VRML 3D models; and here we have two interface DTDs,
one for SVGA and one for OpenGL. We should be able to write
an XPL program type, as a DTD which includes all three of
those other ones, so that an XPL document of this new
compound type can switch between interfaces conditionally
on whichever is available or preferred.
With our xpl-basic facilities, we should even be able to
do arithmetic on the VRML contents, and then pass the
results to the interface.
Which means, we have endowed VRML with arithmetic! And control
flow! Without doing a flaming thing to it internally!
Such is the power of the XPL concept.
Gee, and I'm only up to Point 1. :->
Back soon
Jonathan
God is on the side of the man with the most coloured balloons.
- Arthur Daley
--- End forwarded message ---
|
