[exprla-devel] RE: [XPL] project suggestion

[reid_spencer <ras...@re...>]

--- In xpl-dev@y..., "Richard Anthony Hein" <935551@i...> wrote:
Mark is right.  We need a mandate.  Goal and purpose.  I am looking 
at XPL
as being a chance to reinvent the way people program.  I see it as a 
chance
to explore avenues not yet explored.  Sorry if that isn't what 
everyone else
wants to do.  I will work within the overall vision of the project, 
but that
won't stop me from spitting out ideas that might seem like overboard 
to
others, or in the completely wrong direction.  But we don't really 
have a
direction I can determine.

We really need a requirements draft, then we can all add and update 
parts we
feel need changing.  How about we all submit up to 10 requirements 
each.
Then we'll all take time to consider the requirements, and change the
requirements wording if necessary.  Then we can remove things - the 
ones
that are too much or in a wrong direction, and then go through 
another round
of requirements submissions, including things that the requirements
themselves require.  Then we can debate the final list.  Vote.  Maybe 
have
another round, if enough people think we should.  Submit a working 
draft -
or whatever comes first, I can't remember - to the W3C.

Then we will have our mandate.

Then we look at syntax and things like that.  Maybe this could come 
before
the working draft, I don't know ... I don't think it should though.  
Because
someone who has a real talent for this could come along after we 
submit
recommendations with a great way to do it.  Not to say no one here 
can do
it, the current tag set looks fine, but it's just the beginning of 
something
that should be done really well so as many people as possible can 
understand
it, but it's still simple.  I suppose we could use recommended 
syntaxes from
people before the submission:  One or two syntax recommendations from
people??  Then we can mix and match the best of them?  That could 
work.

Then we start the real heavy work (this doesn't mean you aren't 
thinking
during the earlier process :-) ) of constructing a language, meant to 
be
able to control any variety of devices and users and security 
concerns ...
yeesh.  I'm doing this for what??  :-)  Why climb a mountain, eh? :-D

Anyhow, I recommend that XPL be a full language.  Not just business
transactions.  XPL is TOO extensible to not allow it to fit all 
programming
uses.  Compiled code is machine language binary ... it doesn't matter 
what
language it's written in, therefore XPL could be a base language for 
all
uses, as you should be able to streamline your XPL as a programmer to 
meet
the unique needs of your program.  If you are doing simulations you 
should
be able to write in XPL by using different classes - even ones that 
are
written in other languages, like C++ (of course we can use SOAP to 
allow us
to use this code with XPL - this should be a requirement - but not 
limited
only to SOAP, anyone should be able to extend XPL to utilize other 
means).

I would bet the farm, that the most common use of XPL in the earliest 
period
of growth in this world will be to access pre-built components, like 
COM++
and Java Beans, and your C++ class wrapped in SOAP, and some guy's VB 
module
in Timbuktu.  So, I think XPL should be written in such a way that 
getting
access to these objects should be part of the language so that XPL 
handles
heterogenous components in a way that is easy as pie, tying them 
together
better than anything currently available.  Make a program "serve 
itself" -
accesses the components but really does no processing itself of the 
logic
... the program you write is really just instructions on which 
components to
run and where to send the data next in this type of situation.  And 
so XPL
should be able to do that really well.  Of course we can write logic 
as
well!

I also can't shake the idea of being able to "see" XPL anyway we want 
to.  I
think the IDE is something integrally part of the programming 
language.  It
is because today we see people using all kinds of languages together, 
and
only VS7, which is still vaporware, promises to tie these things 
together.
The VS7 will be a heterogenous one.  I think XPL should allow IDE 
building
to be something uniquely available to the user.  I know that we can 
use XSLT
to do this and it's not fundamental to the actual language.  That's 
the way
it should be.  But, we must build XPL on top of, and around the XSLT 
specs.
XSLT can allow us to use XPL as a symbolic language, verbose language,
simple language, C++ like or even C++, etc...  That's what I mean by 
the IDE
is the language.  People could use a XSLT rendered version of XPL 
that is
itself an interactive IDE.  Placing the cube within a bigger cube 
should
result in XPL code that describes it.  People from any walk of life 
should
be able to use "rendered" XPL in a way that is simple for them to
understand.  This is beyond UML that is tied to the code, or if you 
have
been keeping up with MS stuff, Biztalk Orchestrator, which ties visual
objects to code so business guys can work alongside coders easily, 
and it is
all the same underneath ... they are just representations of the same 
data
(the data being the language of it all).  XPL can and should do this 
and
more in conjunction with XSLT.

If you think that the IDE isn't the language, why is it easier to 
write
using the editor of your choice, then pure text code?  Because people 
speak
that language more easily.  A person who programs in VB sometimes 
barely has
to look at the code.  They use the RAD language subset of VB.  The 
IDE,
especially WYSIWYG editors allow you to speak the language in a way 
that is
easier for you to understand.  XPL should recognize this, and exploit 
it.

This is all work for XSLT to do, but nevertheless, we can make it 
easier for
XSLT to do using XPL!
Hence, XPL should be developed in parallel (in as much as it is 
possible)
with a few standard sets of XSL transformations that build an IDE for 
XPL.
This will teach us what we can do to make it easier and better.

So, for example, I am willing, after we go through the requirement 
stage, to
try to XSL transform some XPL function that performs a simple 
mathematical
function into MathML and back again into XPL.  Something harder, like 
XSL
transforming code that draws a box on screen, then allowing 
manipulation of
the box size, and transform back to XPL sounds harder to me, but we 
should
be able to do it.  Then make it an input box ... things like that.  
These
would, and could be all stages in development to see if it really can 
work
the way I am descibing here.

Sorry if you read all of this ...!

Right now, the requirements are enough to think about.  I'll make up 
my
list.

Richard A. Hein
-----Original Message-----
From: Mark Wilson [mailto:mark_tracey@y...]
Sent: June 10, 2000 8:02 AM
To: xpl@e...
Subject: [XPL] project suggestion



  Is anyone in here interested in outlining this project's goals,
  progress, W3C status(?), integration to other projects and if/how
  people can become involved etc. and forwarding it to me in email, so
  I can list it as an article on
  http://www.vbxml.com

  We get 40 000 unique visitors a month and they would be interested 
in
  something like this.  Regardless of if you want to set up a home
  website on VBXML.COM, I would like to list a detailed description
  (including XML) as an article on VBXML.COM

  Please email responses directly to me.

  Cheers,
  Mark Wilson
  VBXML.COM Admin


----------------------------------------------------------------------
------
--



----------------------------------------------------------------------
------
--
  To unsubscribe from this group, send an email to:
  xpl-unsubscribe@o...
--- End forwarded message ---