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

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

--- In xpl-dev@y..., cagle@o... wrote:
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
  ----- Original Message ----- 
  From: Richard Anthony Hein 
  To: xpl@e... 
  Sent: Saturday, June 10, 2000 11:05 AM
  Subject: RE: [XPL] project suggestion


  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...




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



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