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

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

--- In xpl-dev@y..., "Tony Edgecombe" <tony.edgecombe@f...> wrote:
I have to agree with your comments on an IDE, for the last couple of 
years I
have been working with a product (www.formscape.com) which allows you 
to
build applications in a simple tree based drag and drop environment. 
I can
see a direct corellation between the structure of this tree and some 
of the
schemas talked about early on in this group. In this particular case 
the
software is focussed on formatted output but the principles could 
apply to
any type of application. The big benifit this allows is the 
configuration of
complex applications by non programmers (sometimes!) and very rapid
development because of the high level of abstraction.

It could be that this element of XPL is crucial to the adoption of the
language. XML is not the easiest thing to read or write when littered 
with
namespaces and attributes, anything but the simplist of programs 
could be
very frustating to construct.

Tony


  -----Original Message-----
  From: Richard Anthony Hein [mailto:935551@i...]
  Sent: 11 June 2000 07:34
  To: xpl@e...
  Subject: RE: [XPL] project suggestion


  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

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



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