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

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

--- In xpl-dev@y..., "Richard Anthony Hein" <935551@i...> wrote:
Kurt,

The message board sounds great.  I understand what you are saying 
about
building the architecture, and you are right.  I expect the component 
base
will grow quite quickly over time, once we have that architecture in 
place,
and so I concure.  I would like to hear more about XPipes ... what's 
it all
about - and XSLTalk, for that matter?

When you say, "reduce everything down to the movement of streams" what
exactly do you mean?  I am not sure if you mean, don't worry about
performing operations on the streams?  Also, I am not sure what you 
mean
about emergent patterns ... am I right in thinking you mean to allow 
the
abstract architecture to handle the patterns which components follow 
in
providing parameters for input and output, location, etc ...?  Could 
you
clarify this a bit for me?

Yes, XML is a web language ... but the web is going to be 
everything!  Let's
take it slow and take care of the basics that XML excel in, yes, I 
can see
that, but let's also keep in mind the future, so that we can extend 
it.  I
think making an extensible programming language isn't exactly 
easy ... we
have to think of scenarios that may be required in the future, and 
try to
plan for those eventualities.  You're right, we don't have to build 
it to
handle all the things that are and may decide come along ... it only 
means
we have to be careful, to allow us to extend it to handle the future 
demands
of the web.  So, I do agree, as long as we remember not to lock XPL 
in to
today's internet.  Let's build it for today, and leave room for 
tomorrow,
which XPL should do if the name means anything.

My talk about an IDE is not asking the group to build one now.  It's 
asking
everyone to consider the idea that the IDE can be integrated into the
language itself and the total look and feel of the IDE should be 
linked to
the language in a way that hasn't been done before.  I can almost see 
it as
if when someone goes to start a new project in XPL, the IDE itself 
will
become the application - if it is something that can be visual.  So 
you
start with this bare IDE, and simply select components, and buttons 
and what
not, drop them where you want, and so on.  This sounds just like using
Visual Basic or something so far.  But if you take it a step further, 
then
the application is also an IDE to someone else ... you see?  Then the 
user
can change just about anything about the application, excepting 
perhaps the
code that runs the core logic.  Things like button type, input type 
can be
changed to the users liking, and what not.  Just like Mozilla can be a
browser and the editor for XML pages.  Of course, the authors of the
program, or administrators should also be able to limit that sort of 
thing
if necessary.

I know we won't start by building the IDE, but what considerations do 
we
need to put into the language to make this easier to do later?  Is it
possible?  Does it make sense?  Do we need to put design 
considerations into
the language to support this, or will it work anyways?  Will XSLT do 
it all
for us?  These are questions running through my head.  The bottom 
line for
me, is it would be something wonderful to bring programming to the 
average
Joe.  Maybe not for programmers ... but still.  I hope XPL can do 
that.  So
anyways, before I write anymore, don't worry, I don't mean let's 
build an
IDE now (aside from me trying out an XSLT after we get the 
architecture and
syntax done - come on, it'd be fun!).  I just think it is something 
to think
about during the design of the language.  Others may disagree, and 
almost
certainly know a lot more than I do about this, so I defer to the 
better
judgement of my peers.  An article at www.xml.com about the "Semantic 
Web"
talks about this sort of thing though, and I was hoping we could get 
it to
happen for XPL.  Maybe the group could take a look at the article so 
they
can see where I am coming from with this idea?

I agree with your third paragraph completely, although it might not 
seem
like it from the messages I have been sending.  I am just excited 
about the
possibilities! :-)  We absolutely must have the infrastructure, or 
else
nothing else I have been thinking about will ever work anyways!  So, 
let's
get the requirements together!  I have a few already, but I will send 
that
with the rest, when I get them sorted out.

Thanks Kurt, for being patient (and the rest of XPLers)!  I have never
designed a language before, so bear with me and my far reaching (or 
fetched)
ideas about what it should do!

Richard A. Hein



 -----Original Message-----
From: cagle@o... [mailto:cagle@o...]
Sent: June 11, 2000 12:01 AM
To: xpl@e...
Subject: Re: [XPL] project suggestion


  Richard,

  The requirements document sounds like a solid idea. Let me fill you 
in on
what I'm doing with VBXML -- Mark and I have talked about creating a 
new
site called XSLTalk, where we could set up a forum for handling
requirements.  I worked on a critical part of the XPipes framework 
today,
and may even be in a position in the next couple of days to set up 
message
boards where we could solicit requirements.  That way rather than 
trying to
sort things out in an arbitration process we can set up discussions in
something approaching real time.

  My personal druthers is to take the problem from the other 
direction --
define an architecture for integrating components on a generalized 
basis,
then add to the component base over time. Keep the language itself
relatively self contained, then move device functionality into 
components.
Reduce everything down to the movement of streams that are largely
transparent to device or file type. Abstract as much as possible --
parameters may come from SOAP or query strings or forms or anywhere 
else,
follow emergent patterns rather than provide specificity of code (not 
all
treeviews are created equal, even though the form is common to all).
Remember that XML is first and foremost a web language, and will not 
(and
should not) replace more complex compiled forms yet.  Move the 
language
slowly in that direction, of course, get people to start thinking 
about XML
as a language for handling compiled forms but focus on XMLs strengths 
before
extending the language to better handle its weaknesses.

  As I mentioned previously, I think an XML IDE is a cool idea, and 
should
be considered as a mechanism that could even be built using XPL, but 
I would
caution against concentrating on IDE too soon. In my mind the purpose 
of XPL
is to create an easy to use language that doesn't require a lot of
programming acument, that can be done using the native forms of XML 
without
a lot of exceptions, and that could be written in a text editor if 
need be.
It should be a language that allows for the intermingling of XML (or 
XSLT or
XPL), and that can be extended transparently. The ability to 
communicate
with devices, or handle MathML streams, or to toggle between HTML and 
WML
output should be considered as very much secondary to building a 
cohesive
infrastructure for working with components in the first place.

  I'll put together my requirements list on this and will see about 
getting
the XSLTalk website set up if that is what people are comfortable 
with.

  -- Kurt
--- End forwarded message ---