exprla-devel Mailing List for XPL: eXtensible Programming Language (Page 7)
Status: Pre-Alpha
Brought to you by:
xpl2
Menu
▾
▴
exprla-devel — This is the Developers' list for the for XPL
You can subscribe to this list here.
| 2002 |
Jan
(198) |
Feb
(40) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|
|
From: reid_spencer <ras...@re...> - 2002-01-31 08:57:54
|
--- 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 --- |
|
From: reid_spencer <ras...@re...> - 2002-01-31 08:57:39
|
--- 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 ---
|
|
From: reid_spencer <ras...@re...> - 2002-01-31 08:57:20
|
--- 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 --- |
|
From: reid_spencer <ras...@re...> - 2002-01-31 08:57:05
|
--- In xpl-dev@y..., "Mark Wilson" <mark_tracey@y...> wrote: 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 --- End forwarded message --- |
|
From: reid_spencer <ras...@re...> - 2002-01-31 08:56:36
|
--- In xpl-dev@y..., cagle@o... wrote:
That's right! And we can use the same MathML that we convert
into a functional representation to describe the function in SOAP.
So imagine someone needs function that solves the formula y = 3x +
1/x.
They simply would have to search for the component (it may be in
the library) by writing it this way, or by allowing input into a GUI
template (using XSL) and when they submit, XSLT transforms that input
into MathML content and searches using Service Description Language
in SOAP to find that very function.
It's possible, though keep in mind that there is a distinction
between programmatic mathematics and symbolic mathematics. For
example, I can create a MathML representation of a differential
equation, but there is a distinction between the symbolic solution of
such an equation (which can get to be byzantine) and the numerical
solution of the same equation. In general, most people will opt for
the use of programatic algebraic notations when working through an
interface (or when writing code) -- conceivably it could be converted
into MathML, but I'd be inclined to say that this should more likely
be a persistance solution, a way to either save an equation to a file
or retrieve the equation from the file. Even in the MathML
specifications, the authors readily say that they don't expect MathML
to be authored by hand.
The input could be a MathML stream as well. We could always
layer easier to use names on top of the function real name. In a
business environment y= 3x + 1/x might be used to calculate financial
information, so it could be assigned a name that is appropriate for
that environment, like CalcTax, which takes user input for x and
spits out an integer y, but the real name is the MathML. That way we
could use the very same function to draw the curve y = 3x + 1/x as
part of a simulation program. The curve is drawn by calling the y=3x
+1/x expression and passing in a stream of x, which can be assigned
during the call, as the input parameter. y gets passed out and is
used by the draw function to draw a point (x,y).
There would be reusable code across business types if you could
do this. Why write tons of new code to make a puff of smoke appear
on screen when you can use MathML that describes the behaviour and
search for functions that exist. They could have been created for
any purpose (say, fluid mechanics) but will be usable by your program
to describe the exact behaviour. If there isn't a functional
representation of the MathML available, then you could make one using
our XPL class that interprets equations.
While what you say is true, most people won't be using XML for making
puffs of smoke appear on the screen (though they may use it in
conjunction with mirrors). They'll be using it to write business
logic, to handle transactions, to present information in a cohesive
and consistent manner. They may very well use it for modelling
physical phenomena as well, but here you run into a dual set of
gotchas. Simulations are still one of the areas where efficiency of
process may preclude the use of XML (although that may not be
completely true in the future). A second problem is that the language
to describe such an environment is highly statist upon multiple
processors simultaneously, an area when XML traditionally has had
problems. Still, the concept is valid -- an XPL class that
interpreted MathML could very well handle this, just as in the
example I gave the <xpo:graphics class would provide an interface
between XML data and SVG.
Another way of thinking about XPL is to envision it as being modelled
along the lines of the Java API. The <xpo:graphics> class might
correspond to the java awt.graphics class, for instance. I suspect
that the architecture would work better if the classes were
essentially object like rather than OOP (i.e., more like the flat
VIsual Basic model rather than the hierarchical Java one), although
this doesn't necessarily have to be the case -- assuming that a
compiled model was used -- XPL to XSLT then possibly to compiled
XSLT, then when the XPL is first compiled the imported resources
could potentially themselves import content, which will get rolled
into the final XSLT before it is invoked. Hence a compiled XPL could
support class inheritance... hmmm, will have to think on this one
some more.
Kurt Cagle
--- End forwarded message ---
|
|
From: reid_spencer <ras...@re...> - 2002-01-31 08:56:21
|
--- In xpl-dev@y..., "Richard Anthony Hein" <935551@i...> wrote: -----Original Message----- From: cagle@o... [mailto:cagle@o...] Sent: June 9, 2000 3:03 PM To: xpl@e... Subject: [XPL] Direction and purpose of XP Also, about MathML -- MathML is a markup language for describing both the visual representation of mathematical equations and the conceptual underpinnings of these equations. It doesn't actually contain any code for the interpretation of equations -- this would have to be handled by a third party component. However, there's nothing that says that an XPL class couldn't do just that, converting a MathML stream into a functional representation of that stream; indeed, since the language is basically a pre-processor language that would mean that the MathML representation would be conceivably encoded as a binary executable at that point, which would make it very efficient. That's right! And we can use the same MathML that we convert into a functional representation to describe the function in SOAP. So imagine someone needs function that solves the formula y = 3x + 1/x. They simply would have to search for the component (it may be in the library) by writing it this way, or by allowing input into a GUI template (using XSL) and when they submit, XSLT transforms that input into MathML content and searches using Service Description Language in SOAP to find that very function. The input could be a MathML stream as well. We could always layer easier to use names on top of the function real name. In a business environment y= 3x + 1/x might be used to calculate financial information, so it could be assigned a name that is appropriate for that environment, like CalcTax, which takes user input for x and spits out an integer y, but the real name is the MathML. That way we could use the very same function to draw the curve y = 3x + 1/x as part of a simulation program. The curve is drawn by calling the y=3x +1/x expression and passing in a stream of x, which can be assigned during the call, as the input parameter. y gets passed out and is used by the draw function to draw a point (x,y). There would be reusable code across business types if you could do this. Why write tons of new code to make a puff of smoke appear on screen when you can use MathML that describes the behaviour and search for functions that exist. They could have been created for any purpose (say, fluid mechanics) but will be usable by your program to describe the exact behaviour. If there isn't a functional representation of the MathML available, then you could make one using our XPL class that interprets equations. Am I reaching here? Does any of this make sense to anyone? Richard A. Hein --- End forwarded message --- |
|
From: reid_spencer <ras...@re...> - 2002-01-31 08:56:08
|
--- In xpl-dev@y..., cagle@o... wrote:
I'd like to add a few comments to this:
I think Jonathan sums up the situation very nicely. One of the things
to consider with XML is that it is not a technological standard. I
know this sounds counterintuitive but lets face it, XML is a fairly
indifferent data format, something that's existed for several years
in slightly more arcane form. Rather, XML is a political standard.
It is an agreement between a large and growing number of people to
use the syntax and grammar that's presented in the XML standards
document as the basis for data communications. This holds true for
XSLT and will hold true for schema as well. Already, I'm seeing
situations where companies that attempt to deviate from these
standards (Microsoft comes to mind) discover that while they can
build a better version, it is not a version that people will end up
using because it isn't standard. This is very different from the
situation from HTML, largely because there wasn't the pushback from
the community to maintain the data standards in the same way.
XSLT is a transformative mechanism, and moreover is the accepted
transformative mechanism for XML streams. It is actually very good at
what it needs to do, but suffers somewhat from the limitations
imposed by being a language designed by commitee. There are
provisions in XSLT for extension, however, and these provisions
should be used in any solution built around XSLT. I have built
message board systems and have seen Outlook like applications that
were built largely with XSLT. With XSLT you can generate SVG output
to handle graphics, can transform MathML to handle equation
processing, can (with extensions) handle multiple streams both for
input and output, and so forth.
Consider the need for programming languages in general. Creating a
language like Basic in XML would be somewhat counterproductive -- you
can write VBScript code and use the DOM for that. To modify Basic so
that it can be rendered in XML ends up creating the worst of both --
the verbosity of XML combined with the sometimes wildly inconsistent
representations of commands in VB. If the purpose of the language
is to perform transformations on XML streams (keeping in mind that
setting the state of a device is as valid a transformation as setting
a variable) then XSLT will get you 80% there. By incorporating a
script that can work effectively as an integrated element within XSLT
you can concentrate on the remaining 20% without having to redefine
transformations from the get go: manipulating object references,
performing input/output to devices, event handling, and working with
functional definitions.
One of the biggest problems that XSLT has (and one that I'm lobbying
the W3C to change) is the fact that there is no way to create a
functional reference to a named template. I'd love to see something
like:
<xsl:template name="myFunc">
<xsl:param name="param1"/>
<!-- do something here -->
</xsl:template>
<xsl:value-of select="myFunc('myPassedParamValue')"/>
This is one area where I can see an XPL like piece working, because
it could act as the bridge to do this (you actually can generate one
from the other, but the actual XSLT for the functional output mirrors
the input:
<xsl:variable name="myFunc_call">
<xsl:call-template name="myFunc">
<xsl:with-param name="param1" select="'myPassedParamValue'"/>
</xsl:call-template>
</xsl:variable>
<xsl:value-of select="$myFunc_call"/>
One way that I can see developing XPL would be to create a set of
associated objects that might be written in Java or script, then put
XML wrappers around them and use the extensions from XSLT to
incorporate them. By creating a set of these code components, you can
essentially start developing an API, which is I think where XPL
offers the greatest benefit. That way, you could, taking a cue from
my note yesterday, create an XP routine that could, as an example,
output an integration graph:
<xp:with object="math">
<xp:for var="x" start="0" increment=".01" test="$x <= 1.0"
xsi:type="float">
<xp:var name="y" value="sin($x)*cos(3*$x)*exp(-sqr($x*.025))"
xsi:type="float"/>
<xpo:graphics method="draw_rect" left="{100+$x*200}"
bottom="200" top="{$bottom-200*$y}" right="{$left+$x*199}"
style="background-color:green;border:none;"/>
</xp:for>
</xp:with>
Here there are in fact four distinct objects present -- the math
object, which defines operations like sin(), cos(), etc., the
graphics object, which includes the draw_rect method, the xp object
which handles the language definitions, and the xsi: object, which
handles the XML Schema instance interface for defining datatypes. The
syntax presented here is not all that different from a VB script,
either. The same code written in VB (assuming that VB had a distinct
math object) might look something like:
with math
dim x as double
dim y as double
for x=0 to 1.0 step 0.01
y=sin(x)*cos(3x)*exp(-sqr(x*0.25))
graphics.draw_rect.left=100+x*200
graphics.draw_rect.bottom=200
graphics.draw_rect.top=graphics.draw_rect.bottom-200*y
graphics.draw_rect.right=graphics.draw_rect.left+x*199
graphics.draw_rect.style="background-color:green;border:none;"
next
end with
Nice thing is that the code there could easily be dropped into an
XSLT script. For instance:
<xsl:template name="draw_integration_chart">
<xsl:param name="equation"/>
<xsl:param name="start"/>
<xsl:param name="end"/>
<xsl:param name="delta"/>
<xp:with object="math">
<xp:for var="x" start="$start" increment=".$delta" test="$x
<= $end" xsi:type="float">
<xp:var name="y" value="$equation" xsi:type="float"/>
<xpo:graphics method="draw_rect" left="{100+$x*200}"
bottom="200" top="{$bottom-200*$y}"
right="{$left+$x*199}"
style="background-color:green;border:none;"/>
</xp:for>
</xp:with>
</xsl:template>
<xsl:call-template name="draw_integration_chart">
<xsl:param name="equation" select="sin($x)*cos($x)"/>
<xsl:param name="start" select="0"/>
<xsl:param name="start" select="2"/>
<xsl:param name="start" select="0.02"/>
</xsl:call-template>
Since XPL wouldn't modify the XSLT, things like the $equation would
automatically get expanded before the XSLT even saw it.
The biggest challenge that I can see to a declarative XPL model comes
in an event based environment -- the XP language that I've been
discussing works in a largely declarative fashion -- stream comes in,
an XP generated XSLT script processes the data, output stream(s) are
sent on. I think eventing mechanisms are possible, but I'm still
trying to figure out the most efficient way of handling things like a
mouseclick (i.e. client side issues). In an ideal XP "browser", an
event would send an XML stream to an object script that would trigger
a set of default XP templates:
<event id="onclick" timestamp="2000-06-10T12:15:24" window="main"
x="120" y="169"/>
<eventhandlers>
<when test="@id='onclick'">
<exec select="xpo:this!image_whack(@x,@y)"
</when>
</eventhandlers>
where xpo:this would contain a reference to the object receiving the
event and the default namespace is the xp: namespace. Thus, when the
object is clicked, this.image_whack(120,169) would be called.
The event handler processors would have to be supported by some code
in the background. In other words, an XP client would probably run as
a Java applet or ActiveX object within an XML browser page, although
conceivably down the road this could be incorporated directly into
the browsers.
Sorry for the code intensive response here. I see an XML programming
language as a logical (and necessary) next step to building more
sophisticated applications (I'd like to eliminate Java AND COM
eventually <grin/>). By keeping it object oriented and modular, it
gives the language the capability of adding components directly from
the Internet. Note though that in this approach, the language is
assumed to be largely an integration language along the lines of VB
rather than a highly efficient processing language like C++. Some
components may be written in XPL (or XSLT), some components may be
external COM or Java Classes, some components may be mixtures of the
two. Of course, there's nothing that says you couldn't build an XPL
class that generated code that could be fed into a Java compiler --
that's one of the beauties of XSLT.
Also, about MathML -- MathML is a markup language for describing both
the visual representation of mathematical equations and the
conceptual underpinnings of these equations. It doesn't actually
contain any code for the interpretation of equations -- this would
have to be handled by a third party component. However, there's
nothing that says that an XPL class couldn't do just that, converting
a MathML stream into a functional representation of that stream;
indeed, since the language is basically a pre-processor language that
would mean that the MathML representation would be conceivably
encoded as a binary executable at that point, which would make it
very efficient.
-- Kurt Cagle
----- Original Message -----
From: Jonathan Burns
To: xpl@e...
Sent: Friday, June 09, 2000 7:40 PM
Subject: Re: [XPL] Hello, and a few comments.
Kurt, thanks very much for this thorough review - and for the
invitation.
To my fellow contributing members of the XPL list over the past few
weeks:
I'm going to say something rather geeky here, but I think it's
important.
Kurt's post is a turning-point for the list. Up til now, it's been
reasonable
to see ourselves as working out a complex possibility on our own
initiative,
with our own resources, and within our own limitations. Which, let
us face it,
are considerable. To speak of my own, I'm a raw beginner at even
the basic
Web technologies (still have yet to write a non-trivial CGI
program); and I'm
desperately looking for work, which when I find it will almost
certainly
knock the stuffing out of my concentration time.
Within our limitations, I'd say we've done pretty damn well. We've
managed to
canvass a lot of possibilities for what XPL can be and do. We've
identified
the major technologies where we can expect to find implementational
power,
and also integration with the wider XML community. Not least
important, we've
built up a sense of community, where everyone's contributions are
reoognized,
and nobody is discounted, e.g. for being a Web newbie.
That last one is extremely valuable to me. XPL is where I get to
articulate
ideas which come out of a quarter-century of experience, especially
in
computer science, which don't seem relevant or welcome in any other
context.
There isn't anywhere else quite like XPL, for me.
Now we're being challenged in a sense, to take off the water-wings
and dive
in at the deep end; where there are people like Kurt who have been
three
years at the cutting edge.
Compared to what the W3C/XML community are doing, implementing
QBasic or
Miva as XML documents are very limited goals. I can see larger ones
in
principle - but the limited goals are something we could
realistically
achieve.
Now personally, I like the way that Alexander, Richard and now Kurt
are
raising the stakes. It has already become clear that the whole
gamut of
XML accessories - Xpath, Xlinks, the DOM, XSLT and more -
enormously
extend the answers to the questions, What can we do with and to XML
documents? They may turn out to BE the answers - and they may make
the
whole concept of XPL as a distinct language irrelevant in the end.
Whatever, we will inevitably have to integrate XPL's desing goals
with
them, as Kurt says.
I just think - here's the geeky bit - that in a real sense this is
Michael
Lauzon's group. XPL is his inspiration, he got discussion started,
set up
the forum, and is going to some trouble to maintain it. That
doesn't make
him the boss, or right about everything, but to me it gives his
views
some special authority.
Meaning, that if Mike thinks we should remain an affiliated but
distinct
group, working toward a limited, but definite and achievable goal,
then
I would support that. As far as I could, I would contibute to XPL
and
VBXML both; but I would put my priority effort in making sure that
this
group survives, more or less as it is.
On the other hand, if Mike thinks we can get further by casting our
lot
with VBXML, I think it would be about ideal - with this
qualification:
I need there to be a zone which is newbie-friendly. Some place
where
the dumb questions are asked, and the answers spelled out. And
nobody
is frozen out because they can't follow the jargon. And everybody
gets
respect. If I have to moderate it myself.
See, I think that the XML technologies are ultimately simple. XML
was
designed to be, and that accounts for much of its rapid spread. I
could
teach it to high-school kids. But, there is always the tendency to
speed the discussions with shorthand that turns into private
jargon,
or with high computer-science abstractions, which are already
pretty
cryptic. And that will freeze newcomers out, unless there is a
special
effort made to maintain clarity, and to keep the bridges open
between
the general community and the cutting edge. That special effort is
my
forte - and that's where you'll find me, if necessary at the
expense
of my participation in some of the advanced efforts.
Goodwill
Jonathan
"Oh god. This job application's been a whole year in process!"
"Happy birthday to you, happy birthday to you..."
----------------------------------------------------------------------
--------
----------------------------------------------------------------------
--------
To unsubscribe from this group, send an email to:
xpl-unsubscribe@o...
--- End forwarded message ---
|
|
From: reid_spencer <ras...@re...> - 2002-01-31 08:55:53
|
--- In xpl-dev@y..., "Richard Anthony Hein" <935551@i...> wrote:
Thanks Alexander! I really needed that rundown to clarify what it is
that
everyone has in mind concerning these two and how they compare to
what we
have in mind for the direction XPL will take.
Thanks again!
Richard A. Hein
-----Original Message-----
From: Alexander E. Gutman [mailto:gutman@m...]
Sent: June 9, 2000 6:02 AM
To: xpl@e...
Subject: [XPL] XFA and XML Script
Hello, friends.
I have briefly read the basics of XFA and XML Script.
My raw conclusion: They are not what I want XPL to be alike.
The two main distinctions/disadvantages are as follows:
1. Their purposes are different from that of XPL.
2. They are not purely XML-based languages.
Now some details follow.
XFA vs XPL
0. An XFA program is not a well-formed XML document.
As a result, XSLT is useless here.
Fortunately, there is a strict XML version.
Therefore, I will consider that only case.
1. The output of an XFA program is an HTML document.
Thus, an XFA document looks like and works like just an ASP.
So why not using HTML+JavaScript, as ASPs do?
Just because XFA is an XML instance?
This argument is not very strong due to the disadvantage #2.
By the way, even though XFA has additional advantages
as compared to ASPs (and it does have them),
the output of an XFA program is still an HTML document.
This is not the case if we consider XPL.
Of course, one of the XFA benefits consists in the fact that,
by communicating with an XFA interpreter, you can make
pages active. Actually, an XFA interpreter is a "universal"
script which handles requests from XFA-generated HTML pages.
But this feature does not concern XFA as a language.
2. XFA is not a purely XML-based language.
The XFA documentation states: "Other approaches to processing
XML require the use of another language such as Java or Perl.
With XFA, the only language needed is XML."
Actually, this is not so. Examining the following example
<xfa:val exp='f1("first","This is the first call to f1")'/>
we see that another, non-XML, language is employed.
The question arises again: ASPs also use another language
(JavaScript), so why not using HTML+JavaScript instead?
Contrary to XFA, XPL should be a purely XML-based language.
XML Script vs XPL
1. An XML Script is a transformation program.
Its purpose coincides with that of XSLT.
This is not the case if we consider XPL.
2. XML Script is not a purely XML-based language.
Examining the following example
\# myvalue := 1 \#
\# ++ myvalue \#
we see that another, non-XML, language is employed.
Contrary to XML Script, XPL should be a purely
XML-based language.
--
Alexander E. Gutman
----------------------------------------------------------------------
------
--
----------------------------------------------------------------------
------
--
To unsubscribe from this group, send an email to:
xpl-unsubscribe@o...
--- End forwarded message ---
|
|
From: reid_spencer <ras...@re...> - 2002-01-31 08:55:36
|
--- In xpl-dev@y..., "Richard Anthony Hein" <935551@i...> wrote: I think maybe the problem is that there is doubt over the idea that you can take something like MathML and generate programming logic from that MathML. However, if you can generate MathML from an algorithm, then why can't you go the other way? -----Original Message----- From: Alexander E. Gutman [mailto:gutman@m...] Sent: June 9, 2000 7:27 AM To: xpl@e... Subject: RE: [XPL] Hello, and a few comments. Richard Anthony Hein wrote: > I figure that it would be amazing to use MathML > as the markup that XSLT uses to build a function in XPL! What is "to build a function"? To produce a code for defining a function whose body is, in some sense, equivalent to the corresponding MathML expression? [Richard Anthony Hein] Yes! Exactly. We could build expressions and functions from MathML, that take input parameters from MathML and return MathML. > Any mathematical expression that a mathematician can write > in MathML should be transformable into XPL! ANY mathematical expression? Hmm... If there is no integration operator in XPL's dictionary, how can we transform an expression that involves integration? Do you mean that XPL's dictionary must contain integration operator, etc.? [Richard Anthony Hein] Why not? XPL is extensible ... so you can add strength to the interpreter/complier that reads the MathML as the language grows. If we can instruct the complier how to handle the symbol - in this case integrate - we could make it build an algorithm that will integrate according to the MathML. For cases of integration, we can actually use the proofs themselves (which also happens to be written in MathML) to describe how to build the XPL algorithm. > Algorithms in XPL should be able to be transformed into MathML. This seems reasonable. Alongside presentation considerations, any MathML-compliant software will thus be able to "understand" XPL. [Richard Anthony Hein] Right, but it is the other way that you don't think can work? That is, if we can transform XPL algorithms into MathML expressions, or physics (this is something that would be needed to describe some systems ... I can picture people making their own XPL extensions that describes the system optimally ... we should be able to go the other way as well. Everything that happens inside a computer and on the network can be described by mathematics, therefore MathML is the bottom line. If we describe functionality of a microprocessor using MathML, which could be generated from XSLT that takes design markup from chip manufacturers and makes it MathML, then we would have a low level language that is described by the very markup that built the chip! That would free us from being restricted in chip architecture in the future ... any hardware architecture could be described in MathML which is interpreted into XPL ... VIOLA you have a language specific to the hardware that is extensible, and can be made into function libraries immediately! Yet it can all be XPL! Does anyone see the possibilities? Any way, MathML's Content Markup is a very good example of how XPL expressions should look like. [Richard Anthony Hein] Yes it is! Richard A. Hein -- Alexander E. Gutman ---------------------------------------------------------------------- ------ -- ---------------------------------------------------------------------- ------ -- To unsubscribe from this group, send an email to: xpl-unsubscribe@o... --- End forwarded message --- |
|
From: reid_spencer <ras...@re...> - 2002-01-31 08:54:46
|
--- In xpl-dev@y..., Jonathan Burns <saski@w...> wrote: Kurt, thanks very much for this thorough review - and for the invitation. To my fellow contributing members of the XPL list over the past few weeks: I'm going to say something rather geeky here, but I think it's important. Kurt's post is a turning-point for the list. Up til now, it's been reasonable to see ourselves as working out a complex possibility on our own initiative, with our own resources, and within our own limitations. Which, let us face it, are considerable. To speak of my own, I'm a raw beginner at even the basic Web technologies (still have yet to write a non-trivial CGI program); and I'm desperately looking for work, which when I find it will almost certainly knock the stuffing out of my concentration time. Within our limitations, I'd say we've done pretty damn well. We've managed to canvass a lot of possibilities for what XPL can be and do. We've identified the major technologies where we can expect to find implementational power, and also integration with the wider XML community. Not least important, we've built up a sense of community, where everyone's contributions are reoognized, and nobody is discounted, e.g. for being a Web newbie. That last one is extremely valuable to me. XPL is where I get to articulate ideas which come out of a quarter-century of experience, especially in computer science, which don't seem relevant or welcome in any other context. There isn't anywhere else quite like XPL, for me. Now we're being challenged in a sense, to take off the water-wings and dive in at the deep end; where there are people like Kurt who have been three years at the cutting edge. Compared to what the W3C/XML community are doing, implementing QBasic or Miva as XML documents are very limited goals. I can see larger ones in principle - but the limited goals are something we could realistically achieve. Now personally, I like the way that Alexander, Richard and now Kurt are raising the stakes. It has already become clear that the whole gamut of XML accessories - Xpath, Xlinks, the DOM, XSLT and more - enormously extend the answers to the questions, What can we do with and to XML documents? They may turn out to BE the answers - and they may make the whole concept of XPL as a distinct language irrelevant in the end. Whatever, we will inevitably have to integrate XPL's desing goals with them, as Kurt says. I just think - here's the geeky bit - that in a real sense this is Michael Lauzon's group. XPL is his inspiration, he got discussion started, set up the forum, and is going to some trouble to maintain it. That doesn't make him the boss, or right about everything, but to me it gives his views some special authority. Meaning, that if Mike thinks we should remain an affiliated but distinct group, working toward a limited, but definite and achievable goal, then I would support that. As far as I could, I would contibute to XPL and VBXML both; but I would put my priority effort in making sure that this group survives, more or less as it is. On the other hand, if Mike thinks we can get further by casting our lot with VBXML, I think it would be about ideal - with this qualification: I need there to be a zone which is newbie-friendly. Some place where the dumb questions are asked, and the answers spelled out. And nobody is frozen out because they can't follow the jargon. And everybody gets respect. If I have to moderate it myself. See, I think that the XML technologies are ultimately simple. XML was designed to be, and that accounts for much of its rapid spread. I could teach it to high-school kids. But, there is always the tendency to speed the discussions with shorthand that turns into private jargon, or with high computer-science abstractions, which are already pretty cryptic. And that will freeze newcomers out, unless there is a special effort made to maintain clarity, and to keep the bridges open between the general community and the cutting edge. That special effort is my forte - and that's where you'll find me, if necessary at the expense of my participation in some of the advanced efforts. Goodwill Jonathan "Oh god. This job application's been a whole year in process!" "Happy birthday to you, happy birthday to you..." --- End forwarded message --- |
|
From: reid_spencer <ras...@re...> - 2002-01-31 08:54:20
|
--- In xpl-dev@y..., Michael Lauzon <ce940@f...> wrote: In response to Kurt talking about XMLHTTP & SOAP. I originally had an idea to create something called XTTP (eXtensible Text Transfer Protocol), which the name says it all, then SOAP & XMLHTTP came along. You can still find the group on eGroups, but I found it pointless because of the other two. Though I do not find XPL pointless, yes, we have other groups doing similiar stuff (e.g. XMLScript, XFA). More people will hear about this, eventually...once we get a website up for it, and also examples and whatnot. Michael http://www.geocities.com/SiliconValley/Way/9180/ 'Eat, drink, and be merry, for tomorrow you may work.' --- End forwarded message --- |
|
From: reid_spencer <ras...@re...> - 2002-01-31 08:40:55
|
--- In xpl-dev@y..., Michael Lauzon <ce940@f...> wrote: Yes, I took a look at both of them, and quite frankly speaking...you have to be a genius to learn XMLScript & XFA; when I came up with the idea for XPL, I wanted it to be very powerful, but easy to use and learn. So, you see the problem with XMLScript & XFA. On Thu, 8 Jun 2000, Richard Hein wrote: > I think that we better all look at these two languages, because they > cross over into what we are discussing, and unless you want to > reinvent the wheel, it would be foolish to ignore it. I am > disapointed in the group for ignoring my messages, if that's what is > going on. Maybe you are all looking at it now, and haven't had time > to respond ... if so I apologize ... but I for one don't want to > waste my time doing something that someone else is working on and is > way ahead on, and is bound to make a formal specification and > recommendation to the W3C. > > Isn't there any input on XFA and XMLScript? > > Richard A. Hein > > > -------------------------------------------------------------------- ---- > IT Professionals: Match your unique skills with the best IT projects at > http://click.egroups.com/1/3381/1/_/809694/_/960490798/ > -------------------------------------------------------------------- ---- > > To unsubscribe from this group, send an email to: > xpl-unsubscribe@o... > > > > Michael http://www.geocities.com/SiliconValley/Way/9180/ 'Eat, drink, and be merry, for tomorrow you may work.' --- End forwarded message --- |
|
From: reid_spencer <ras...@re...> - 2002-01-31 08:40:38
|
--- In xpl-dev@y..., "Alexander E. Gutman" <gutman@m...> wrote: Richard Anthony Hein wrote: > I figure that it would be amazing to use MathML > as the markup that XSLT uses to build a function in XPL! What is "to build a function"? To produce a code for defining a function whose body is, in some sense, equivalent to the corresponding MathML expression? > Any mathematical expression that a mathematician can write > in MathML should be transformable into XPL! ANY mathematical expression? Hmm... If there is no integration operator in XPL's dictionary, how can we transform an expression that involves integration? Do you mean that XPL's dictionary must contain integration operator, etc.? > MathML expressions could be used to supply data to those functions What is "to supply data"? To serve as a "source" for the function's body? Actually, I have no clear picture of how XPL (as a language) can employ MathML to a great extent. Probably, you are talking about interpretation of XPL programs rather than XPL as a language itself. > Algorithms in XPL should be able to be transformed into MathML. This seems reasonable. Alongside presentation considerations, any MathML-compliant software will thus be able to "understand" XPL. Any way, MathML's Content Markup is a very good example of how XPL expressions should look like. -- Alexander E. Gutman --- End forwarded message --- |
|
From: reid_spencer <ras...@re...> - 2002-01-31 08:40:13
|
--- In xpl-dev@y..., "Richard Anthony Hein" <935551@i...> wrote: I will reply to your message after I get some sleep but I had to say, I figure that it would be amazing to use MathML as the markup that XSLT uses to build a function in XPL! Any mathematical expression that a mathematician can write in MathML should be transformable into XPL! MathML expressions could be used to supply data to those functions (think integration, calculus formulas building algorithms to model a system ... graphics, sound, simulation, math research (use combinations that are auto generated to try to find the missing pieces of an existing solution) ... wow! Physics markup too! We could use the tags as function names themselves (that can be replaced with user-friendly names in a XSLT transformation (ie... math in MathML, Physics in Physics markup (whatever it's called, and if it exists ...), graphics in SVG and so on. I see it as allowing any expression in data form could be used to program other data, or even itself! For instance, a MathML expression could be compiled and create another instance of itself that it instantiates during execution, then it compliles the new instance in turn, which executes, compiles, creates, and so on forever ... uh oh.... Well, I hope it's not that easy .... Security is something that is a top priority. Algorithms in XPL should be able to be transformed into MathML. We may EVEN be able to use XML used to describe chip operation and circuit design to map out MathML equations used to control the chip build expressions and functions in XPL, use XSLT to generate others layers that describe components then objects that provide ever increasing ability to simplify to a RAD type environment which calls a lot of pre-built components, and lets you remove XSLT layers to get down to the CPU level if you had to build your code from the ground up! If MathML expressions and physics markup can be leveraged this way ... wow ... it blows my mind! I think that parser/compiler (which would it be?) could take these as the language to describe numerical datatypes, which can change with MathML if a new type of number is invented (think imaginary number ... it is a relatively new type) or we need more bits. It could operate on MathML and be operated on by upper layers, and used to build upper layers. That is, we take the tags in MathML and build a function that integrates x/y and name the function using the MathML that built it. That's self describing software. So someone can search for MathML expressions and find the function that evaluates it! When we call the function we supply the MathML expression and tell it which XML document and nodeset (using XPointer) to use as input parameters, mapping them to the values in the MathML expression. Since math and physics use variables in calculations like x=2y^6, we could use the URI to evaluate an expression that uses ns:x = 2y^6 (expr. would be MathML transformed into XPL function which gets y as input from an XML document or other node of MathML) as the x input for the expression RT= 2*(x-1)^7. This is just an example ... I don't even know what RT means here. Richard A. Hein I wanted to get this out, and tried to explain it as best I could at this point (6:00am!). I am beat and am starting to think I might wake up tomorrow and this will have been one of those dream ideas that only makes sense while you are sleeping! --- End forwarded message --- |
|
From: reid_spencer <ras...@re...> - 2002-01-31 08:39:52
|
--- In xpl-dev@y..., "Alexander E. Gutman" <gutman@m...> wrote:
Hello, friends.
I have briefly read the basics of XFA and XML Script.
My raw conclusion: They are not what I want XPL to be alike.
The two main distinctions/disadvantages are as follows:
1. Their purposes are different from that of XPL.
2. They are not purely XML-based languages.
Now some details follow.
XFA vs XPL
0. An XFA program is not a well-formed XML document.
As a result, XSLT is useless here.
Fortunately, there is a strict XML version.
Therefore, I will consider that only case.
1. The output of an XFA program is an HTML document.
Thus, an XFA document looks like and works like just an ASP.
So why not using HTML+JavaScript, as ASPs do?
Just because XFA is an XML instance?
This argument is not very strong due to the disadvantage #2.
By the way, even though XFA has additional advantages
as compared to ASPs (and it does have them),
the output of an XFA program is still an HTML document.
This is not the case if we consider XPL.
Of course, one of the XFA benefits consists in the fact that,
by communicating with an XFA interpreter, you can make
pages active. Actually, an XFA interpreter is a "universal"
script which handles requests from XFA-generated HTML pages.
But this feature does not concern XFA as a language.
2. XFA is not a purely XML-based language.
The XFA documentation states: "Other approaches to processing
XML require the use of another language such as Java or Perl.
With XFA, the only language needed is XML."
Actually, this is not so. Examining the following example
<xfa:val exp='f1("first","This is the first call to f1")'/>
we see that another, non-XML, language is employed.
The question arises again: ASPs also use another language
(JavaScript), so why not using HTML+JavaScript instead?
Contrary to XFA, XPL should be a purely XML-based language.
XML Script vs XPL
1. An XML Script is a transformation program.
Its purpose coincides with that of XSLT.
This is not the case if we consider XPL.
2. XML Script is not a purely XML-based language.
Examining the following example
\# myvalue := 1 \#
\# ++ myvalue \#
we see that another, non-XML, language is employed.
Contrary to XML Script, XPL should be a purely
XML-based language.
--
Alexander E. Gutman
--- End forwarded message ---
|
|
From: reid_spencer <ras...@re...> - 2002-01-31 08:39:48
|
--- In xpl-dev@y..., "Alexander E. Gutman" <gutman@m...> wrote:
Hello, friends.
I have briefly read the basics of XFA and XML Script.
My raw conclusion: They are not what I want XPL to be alike.
The two main distinctions/disadvantages are as follows:
1. Their purposes are different from that of XPL.
2. They are not purely XML-based languages.
Now some details follow.
XFA vs XPL
0. An XFA program is not a well-formed XML document.
As a result, XSLT is useless here.
Fortunately, there is a strict XML version.
Therefore, I will consider that only case.
1. The output of an XFA program is an HTML document.
Thus, an XFA document looks like and works like just an ASP.
So why not using HTML+JavaScript, as ASPs do?
Just because XFA is an XML instance?
This argument is not very strong due to the disadvantage #2.
By the way, even though XFA has additional advantages
as compared to ASPs (and it does have them),
the output of an XFA program is still an HTML document.
This is not the case if we consider XPL.
Of course, one of the XFA benefits consists in the fact that,
by communicating with an XFA interpreter, you can make
pages active. Actually, an XFA interpreter is a "universal"
script which handles requests from XFA-generated HTML pages.
But this feature does not concern XFA as a language.
2. XFA is not a purely XML-based language.
The XFA documentation states: "Other approaches to processing
XML require the use of another language such as Java or Perl.
With XFA, the only language needed is XML."
Actually, this is not so. Examining the following example
<xfa:val exp='f1("first","This is the first call to f1")'/>
we see that another, non-XML, language is employed.
The question arises again: ASPs also use another language
(JavaScript), so why not using HTML+JavaScript instead?
Contrary to XFA, XPL should be a purely XML-based language.
XML Script vs XPL
1. An XML Script is a transformation program.
Its purpose coincides with that of XSLT.
This is not the case if we consider XPL.
2. XML Script is not a purely XML-based language.
Examining the following example
\# myvalue := 1 \#
\# ++ myvalue \#
we see that another, non-XML, language is employed.
Contrary to XML Script, XPL should be a purely
XML-based language.
--
Alexander E. Gutman
--- End forwarded message ---
|
|
From: reid_spencer <ras...@re...> - 2002-01-31 08:39:15
|
--- In xpl-dev@y..., cagle@o... wrote: ----- Original Message ----- From: Richard Anthony Hein To: xpl@e... Sent: Thursday, June 08, 2000 11:48 PM Subject: RE: [XPL] Hello, and a few comments. Some excellent input Kurt! I'll admit, I don't know enough about namespaces right now to fully understand what you are saying, so I will hold off comments until I get read up on the subject. However, I will point out that we need to watch the W3C on the namespaces and URI issue before we really get something set in stone over this, unless we plan for whatever contingencies may result from their final recommendation, or build enough flexibility in to deal with this sort of change in the future. If I am not mistaken here, we could do the latter using schemas, thus allowing updates now and in the future to be easily integrated without breaking anyone's code. However, I don't know enough about namespaces right now - perhaps someone can enlighten me further on the issue relating to the problem with the recommendation? I've actually been thinking about the schema issue quite a bit. Schemas provide an interesting mechanism for defining type both at the simple and the complex level. Thus, I could actually scoping out the type of a variable before assigning it -- a simple case being something like: <xp:define name="item_count" xsi:type="nonnegativeInteger"/> while a class instance could utilize predefined object types: <xp:define name="window" xsl:type="Window_Class"/> Namespaces are generally viewed as necessary evils in XML -- they have just moved too far with namespaces in place to effectively walk away from them now. If they do in fact change the namespace recommendation (and there are some serious flaws, especially in the area of XSLT) then I think that XPL could still largely recover -- the question of differentiating the namespaces is still too critical an issue. I would also like to note that XPL should be built with the "semantic user interface" in mind, as described this week at www.xml.com, making it easy to write code that allows this to take place ... preferably with XForms, although I suppose it could just use XML/XSL. I like the idea of the XML BEING the user interface semantics ... it opens up a whole area to be explored in user customization. It sounds like it might be worth differentiating between XPL and the XPL IDE. Visual Basic, for example, is a language -- a set of keywords that can be used to tie component architectures together. Visual Basic is also an IDE, and this has the drag and drop elements, the script windows, the object palettes, etc. For clarity, let's keep the language architecture itself called XPL, while the interface description language could be called something like XPLODE (XML Programming Language Object Definition Language). There's no reason why you couldn't incorporate XForms into your XSLT architecture -- XForms basically describe the characteristics of the form, while XSLT can be used to generate or populate such forms (I actually have an XSLT template that does something very similar). The XPLODE interface in general would be one that was specifically not tied into a given browser -- it would describe icon elements, buttons, and so forth, but would do so in such a way that an Opera or Netscape 6 or IE 5 browser would all be equally capable of being used to host the IDE. In essence XPLODE provides the metadata that would then be transformed to create appropriate skins for the respective browsers. One additional benefit to following this approach is that you can use the browser as your IDE to develop your code, making it ideal for working over distributed environments. I'd like to see some form of an XMLHTTP like component that would also let you communicate directly with the server -- which would presumably be a Java applet on the Netscape/Opera side and the XMLHTTP component on the IE side. Thus, you'd need to have a fairly powerful browser to handle the production of code, but it wouldn't necessarily rely specifically on one implementation of that code. And finally, I think that we should build XPL to take full advantage of the network protocols enabled by the model which Gnutella offers, enabling the use of COM objects and the like remotely and allowing calls to web services and such technologies coming into being. Gnutella allows a different kind of communication that will be helpful in many ways; for example, it would allows searches that could search for COM objects on a computer somewhere (not necessarily a server), and leverage it. Not only that, but because there are probably going to be many instances of the COM objects on many different computers, it would allow XPL to find the fastest location from which to call the COM object, improving performance. This would also allow us to search for classes, class libraries, methods, functions, etc ... by their descriptions, as defined by Service Description Language, or the like when a component, class, etc ... is missing for some reason - that is, it would allows automatic repair. I'd be VERY careful about this. The Gnutella approach is intriguing, but it relies too much on the off chance that someone would be dumb enough to expose COM objects in the open. MP3s, yes. DLLs, not a snowball's chance in hell. If I can make a couple of proposals here - - Sun has become the third major player (after Microsoft and IBM) to adopt the use of SOAP as a distributed language protocol, and I suspect that SOAP servers will become commonplace on Linux boxes as a consequence. I'm not wild about SOAP from a conceptual standpoint, but I will readily admit that if the PTB all decide to make SOAP available, I'll use it. SOAP servers include a mechanism for discovery that is XML based, obviating the need for messing with other protocols besides HTTP, and SOAP isn't under legal fire in the same way that Gnutella is. Now, that doesn't mean that we couldn't combine a Gnutella like search with a SOAP interpreter... Another advantage to SOAP is that it is language neutral -- you can create a SOAP query against a Java object just as readily as you can against a COM object. It also provides an interface for handling data into SQL Server stores We could also use the same methods to evolve the XPL language, by somehow tagging those objects by performance (perhaps store the results in databases ... marking them by GUID, so the calling object checks this information, then does a search by Gnutella fashion by GUID - making a failsafe method of finding the object if it exists), using tests which would be created by web services. Then we could discover the most efficient objects that can perform the given operation and still yield the best result. This would serve to evolve the language, and avoid confusion about the best methods to invoke and objects to call. Incorporate the GUID into the URN. This is where namespaces come into play again. You create a namespace associated with a unique URN, then maintain repositories that map the URNs to specific object descriptions and locations -- at the very least, this would give you an easy way to locate specific classes, and if you built in a schema protocol of some sort that give interface hooks to class definitions (something that I believe is currently evolving within SOAP anyway) then you could actually use one or more machines as proxies. I think these last few suggestions would make XPL unique (so would cross language transformation and extensibility), in the same way Java was uniquely built for networks. Now we have a new networking paradigm to work with. Let's use it to our advantage. Let's also figure out how to build security that can deal with this into XPL. I have long felt that Java was not built for networks -- it was built as a stripped down version of C++, and it incorporated basic socket capabilities early on because the technology was there. XML is probably one of the first major network paradigms. Security worries me. We're dealing with a language that could simultaneously communicate over potentially tens of thousands of machines, and we better make sure that a compelling security story exists. And finally, let's make XPL in such a way, that the programming convention is customizable to a user's mode of thinking ... that is, let's use XSLT to transform the elements and attributes into customizable "analogies". Since I am thinking that this doesn't really explain what I mean, here's an example: A computer scientist will be familiar with ideas like methods, objects, functions, etc .... A biologist works with proteins, organelles, DNA strands, tissue, and so on .... A chemist thinks in terms of reactions, substrates, molecules, and so on .... An engineer thinks in engineering terms, and so on. Can we make it so that people can transform the tag names, and attribute names, and syntax structure? Basically, let's separate the function of the syntax from the naming conventions. This might sound hard, but why not? Really it is just a transformation over the real underlying naming convention - the "actual" language is a set in schemas, but can be displayed differently for any users. Think about how you could alter it to be like your favorite, and your decidely easiest format to understand - layout operators like in C++, declare variables VB fashion, etc ... but it's all XPL really .... That sounds to me like its actually a schema issue. The geneticist working with DNA will be dealing with a set of well established bio- engineering schemas, and over time will likely evolve (sorry) a class of operations that can be handled on these schemas. Visually, this may be something as simple as dragging a Gene object into the work area. The gene schema has a specific URN, as well as a possible inherited URN, and transformations that can act on that Gene would be keyed to the URN. Thus, not only could the geneticist set a number of properties on the dragged object, but would expose a set of methods appropriate to that class of object (splice, createProtein, etc.) I'm fading here, but I'd like to continue this discussion. -- Kurt What do you think? Richard A. Hein -----Original Message----- From: Kurt Cagle [mailto:cagle@o...] Sent: June 8, 2000 8:29 PM To: xpl@e... Cc: Mark Wilson Subject: [XPL] Hello, and a few comments. Just a brief introduction. My name is Kurt Cagle, and I am a writer and programmer specializing in XML related issues. I was one of the starting writers for Fawcette's XML Magazine, and have written books for Microsoft, Wrox, Coriolis and Sybex on XML. I'm currently working on the XSLT documentation for the MSDN website. I'm a fair VB programmer (I've written a book VB and web technology) but I've basically been living, eating and breathing XML, XSLT and XML Schema for the past three years. I was forwarded the xpl address by Mark Wilson, and am writing to get involved with what is happening here. I want to second his comments that VBXML is made up of a number of developers that are dealing with programming XML at any number of different levels -- the VB side is very much secondary to the XML side. I would heartily recommend that you bring the superb discussion I've seen thus far into VBXML -- I think it would be invaluable for making XPL a viable language. Concerning XPL, I'd like to add my two cents worth into the discussion -- one of the things that I've been doing with Mark is putting together an XSLT based framework, and XPL seems like a good place to explore in attempting to put this together. My own sense of the programming language interface that needs to be addressed involves a number of different aspects: a.. XLST Integration. XSLT is the programming language for XML. Any XPL language needs to recognize this as a central tenet. As I see it, the language should be something that can exist as a namespace addition to XSLT, which has a basic (albeit currently somewhat crude) mechanism for extending XSLT itself. James Clarke's XT contains hooks for Java through a namespace, and the MSXML3 parser lets you both create objects and instantiate existing COM objects (sort of) through the same mechanism. b.. Declarative vs. Procedural Programming. XSLT is fundamentally declarative, even in its use of named templates and parameters. The temptation to make the XPL language procedural is pretty strong, but I would personally argue that it is one that needs to be resisted. Procedural programs tend to encourage statist thinking, work best for synchronous (local) communication, and can already be readily emulated with languages like JavaScript. Any XPL language should be largely syncretic -- it should be possible using XPL to create other XPL programs dynamically, because one of the real strengths of XSLT (one that hasn't been explored yet) is that XSLT allows for the creation of code through automated processes. c.. Multi-pass compilation. One of the things that I'm doing with the XMLPipes framework that I'm writing is to view the XP code as being the easier to author source code that is in turn compiled into XSLT transformations that can be handled by existing processes. The compilation is itself handled through an extended XSLT transformation -- the source code, being an XML document, would tell the XSLT compiler to introduce external XSLT stylesheets that contain specialized code. This code that is created would then consist not of a single XSLT document, but rather an XSLT document that contains import code for other XSLT filters. One advantage to this approach is that a number of the major XML parser designers include the ability to compile and persist XSLT as binary objects, making them much more efficient for scalability purposes. d.. Object Oriented. This goes without saying. Something that I've been playing with has been the development of object oriented XSLT filters -- you create an instance of an object, such as a Table Filter, that can take a data stream and additional elements as parameters as well as an action parameter that determines the method to be invoked: <xpo:table_filter action="display_wml_format" source="$my_stream" output="new_table"/> a.. This call would take the contents of the $my_stream variable, apply the display_wml_format in the table_filter object, then place the resulting xml into a new variable called $new_table. This might be first pass transformed into an XSLT script looking something like: <!-- in the header --> <xsl:import href="table_filter.xsl"/> <!-- in the body of the transform --> <xsl:variable name="temp_1"> <xsl:call-template name="table_filter"> <xsl:with-param name="action" select="'display_wmil_format'"/> <xsl:with-param name="source" select="$my_steam"/> </xsl:call-template> </xsl:variable> <xsl:variable name="new_table" select="node-set($temp_1)"/> a.. Of course, if no output attribute existed, then the contents from the call would go directly into the default output stream. An alternative functional form might also be possible: <xp:out>xpo:table_filter!display_wml_format($my_stream) </xp:out> a.. which would send the contents directly to the output stream. In this case, xp: is the XML Pipes native namespace, while the xpo: namespace corresponds to XML Pipe Objects. This could even be simplified further as: <xp:with object="xpo:table_filter"> <xp:out>display_wml_format($my_stream)</xp:out> </xp:with> a.. which corresponds roughly to the VB With keyword, assigning a given object as the scope of all functions for the duration of the with statement. a.. b.. Add constructs rather than create one from whole cloth. You can do a fair amount already with XSLT. If XPL is to succeed, it should add constructs that add functionality to XSLT -- it'll make it easier to adopt, make it easier to templatize, and will allow you to incorporate XSLT calls within your XPL script (the first pass transformation would simply adopt a different namespace designation for the XSLT keywords, a common enough practice). For example, it would be useful at times to include an indexed for to the for-each statement that currently exists: <table> <xp:for start="1" index="i" test="$i <= 20"> <row> <cell>{$i}</cell> <cell>{$i*$i}</cell> </row> </xp:for> </table> This would end up creating a table iterating from 1 to 20 inclusive, with the value and the square of the value in contiguous cells. Again, though this would be post processed into XSLT, which would probably have to do a structure like: <xsl:template name="for"> <xsl:param name="i" select="1"/> <xsl:param name="increment" select="1"/> <row> <cell><xsl:value-of select="$i"/></cell> <cell><xsl:value-of select="$i*$i"/></cell> </row> <xsl:if test="$i <=20"> <xsl:call-template name="for"> <xsl:with-param name="i" select="$i+$increment"/> <xsl:with-param name="increment" select="$increment"/> </xsl:if> </xsl:template> By doing this, you replace a complicated structure with a much simpler one without having to write a parser that handles the internal task of iterating. Note also the use of the XSLT bracket elements {} to handle evaluation of content into the output stream. This is essentially the same as <xp:out></xp:out>. b.. Use XPL calls for handling external objects. One of the areas that involves the biggest amount of work would be an extension that would let you communicate with external objects. By hiding it behind an xpo: namespace, you could hide the differentiation between internal objects and COM interfaces: <xp:declare_new_object name="fso" href="Scripting.FileSystemObject" type="COM"/> <xp:exec cmd="fso:createTextFile('NewFile.txt',2)" var="txtfile"/> <xp:out>$txtfile!ReadAll()</xp:out> This would create a file system object (a COM object), would execute the method createTextFile on the object and assign the handle to the $txtfile variable, which could then call the RealAll method and output the results into the output stream. c.. Pass server variables in as parameters. Much of XSLT involves parameterization of form or query string data. Variables can be declared within XP that automatically fill with the server variable if it is passed: <xp:query var="page"/> <xp:query var="item_number"/> For the query string "mydoc.xp?page=4&item_number=6" then this will be converted into: <xsl:param name="page" select="4"/> <xsl:param name="item_number" select="6"/> Since the XSLT is compiled afterwards itself into a binary, the page and item_number parameters can be set through DOM calls at some later point. Additionally, server variables such as QUERY_STRING are automatically added to the list of available parameters, so that you could use $QUERY_STRING as an expression without having to explicitly declare it. d.. Verbosity. XSLT is verbose in part because of the use of namespaces, and in part because the architecture favors the use of recursive structures over procedural ones, which in turn tends to stress template blocks that can get hideously complex. However, using a two pass architecture you can turn a significant amount of your code into either tag and attribute forms, or executable line calls. You could even create multiline script blocks using this architecture, since the code will be converted into XSLT that would be manipulatible: <xp:for index="i" start="0" test="$i < 20" output="$sum"> <xp:var name="j" init_value="0"/> <xp:var name="sum" init_value="0"/> <xp:script> $j=$j+$i; $sum=$sum+$j; </xp:script> </xp:for> While this is a little more complex that the equivalent procedural code, it's not that much worse: function sum(){ var j = 0; var sum = 0; for (i=0;i<20;i++){ j=j+i; sum=sum+j; } return sum; } These are just a few thoughts on the issue. In the main, I would suspect that if XPL can stick closely to the XSLT/XPath specifications, enhance rather than replace functionality, and work with a dual path architecture that will transform the XPL into a compiled XSLT form (a la the MS Processor object) it will make for a far more flexible language. Kurt Cagle XML Pro, Fawcette/DevX cagle@o... (360) 951-6159 ---------------------------------------------------------------------- ------ ---------------------------------------------------------------------- ------ 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 --- |
|
From: reid_spencer <ras...@re...> - 2002-01-31 08:38:54
|
--- In xpl-dev@y..., "Richard Anthony Hein" <935551@i...> wrote: Some excellent input Kurt! I'll admit, I don't know enough about namespaces right now to fully understand what you are saying, so I will hold off comments until I get read up on the subject. However, I will point out that we need to watch the W3C on the namespaces and URI issue before we really get something set in stone over this, unless we plan for whatever contingencies may result from their final recommendation, or build enough flexibility in to deal with this sort of change in the future. If I am not mistaken here, we could do the latter using schemas, thus allowing updates now and in the future to be easily integrated without breaking anyone's code. However, I don't know enough about namespaces right now - perhaps someone can enlighten me further on the issue relating to the problem with the recommendation? I would also like to note that XPL should be built with the "semantic user interface" in mind, as described this week at www.xml.com, making it easy to write code that allows this to take place ... preferably with XForms, although I suppose it could just use XML/XSL. I like the idea of the XML BEING the user interface semantics ... it opens up a whole area to be explored in user customization. And finally, I think that we should build XPL to take full advantage of the network protocols enabled by the model which Gnutella offers, enabling the use of COM objects and the like remotely and allowing calls to web services and such technologies coming into being. Gnutella allows a different kind of communication that will be helpful in many ways; for example, it would allows searches that could search for COM objects on a computer somewhere (not necessarily a server), and leverage it. Not only that, but because there are probably going to be many instances of the COM objects on many different computers, it would allow XPL to find the fastest location from which to call the COM object, improving performance. This would also allow us to search for classes, class libraries, methods, functions, etc ... by their descriptions, as defined by Service Description Language, or the like when a component, class, etc ... is missing for some reason - that is, it would allows automatic repair. We could also use the same methods to evolve the XPL language, by somehow tagging those objects by performance (perhaps store the results in databases ... marking them by GUID, so the calling object checks this information, then does a search by Gnutella fashion by GUID - making a failsafe method of finding the object if it exists), using tests which would be created by web services. Then we could discover the most efficient objects that can perform the given operation and still yield the best result. This would serve to evolve the language, and avoid confusion about the best methods to invoke and objects to call. I think these last few suggestions would make XPL unique (so would cross language transformation and extensibility), in the same way Java was uniquely built for networks. Now we have a new networking paradigm to work with. Let's use it to our advantage. Let's also figure out how to build security that can deal with this into XPL. And finally, let's make XPL in such a way, that the programming convention is customizable to a user's mode of thinking ... that is, let's use XSLT to transform the elements and attributes into customizable "analogies". Since I am thinking that this doesn't really explain what I mean, here's an example: A computer scientist will be familiar with ideas like methods, objects, functions, etc .... A biologist works with proteins, organelles, DNA strands, tissue, and so on .... A chemist thinks in terms of reactions, substrates, molecules, and so on .... An engineer thinks in engineering terms, and so on. Can we make it so that people can transform the tag names, and attribute names, and syntax structure? Basically, let's separate the function of the syntax from the naming conventions. This might sound hard, but why not? Really it is just a transformation over the real underlying naming convention - the "actual" language is a set in schemas, but can be displayed differently for any users. Think about how you could alter it to be like your favorite, and your decidely easiest format to understand - layout operators like in C++, declare variables VB fashion, etc ... but it's all XPL really .... What do you think? Richard A. Hein -----Original Message----- From: Kurt Cagle [mailto:cagle@o...] Sent: June 8, 2000 8:29 PM To: xpl@e... Cc: Mark Wilson Subject: [XPL] Hello, and a few comments. Just a brief introduction. My name is Kurt Cagle, and I am a writer and programmer specializing in XML related issues. I was one of the starting writers for Fawcette's XML Magazine, and have written books for Microsoft, Wrox, Coriolis and Sybex on XML. I'm currently working on the XSLT documentation for the MSDN website. I'm a fair VB programmer (I've written a book VB and web technology) but I've basically been living, eating and breathing XML, XSLT and XML Schema for the past three years. I was forwarded the xpl address by Mark Wilson, and am writing to get involved with what is happening here. I want to second his comments that VBXML is made up of a number of developers that are dealing with programming XML at any number of different levels -- the VB side is very much secondary to the XML side. I would heartily recommend that you bring the superb discussion I've seen thus far into VBXML -- I think it would be invaluable for making XPL a viable language. Concerning XPL, I'd like to add my two cents worth into the discussion -- one of the things that I've been doing with Mark is putting together an XSLT based framework, and XPL seems like a good place to explore in attempting to put this together. My own sense of the programming language interface that needs to be addressed involves a number of different aspects: a.. XLST Integration. XSLT is the programming language for XML. Any XPL language needs to recognize this as a central tenet. As I see it, the language should be something that can exist as a namespace addition to XSLT, which has a basic (albeit currently somewhat crude) mechanism for extending XSLT itself. James Clarke's XT contains hooks for Java through a namespace, and the MSXML3 parser lets you both create objects and instantiate existing COM objects (sort of) through the same mechanism. b.. Declarative vs. Procedural Programming. XSLT is fundamentally declarative, even in its use of named templates and parameters. The temptation to make the XPL language procedural is pretty strong, but I would personally argue that it is one that needs to be resisted. Procedural programs tend to encourage statist thinking, work best for synchronous (local) communication, and can already be readily emulated with languages like JavaScript. Any XPL language should be largely syncretic -- it should be possible using XPL to create other XPL programs dynamically, because one of the real strengths of XSLT (one that hasn't been explored yet) is that XSLT allows for the creation of code through automated processes. c.. Multi-pass compilation. One of the things that I'm doing with the XMLPipes framework that I'm writing is to view the XP code as being the easier to author source code that is in turn compiled into XSLT transformations that can be handled by existing processes. The compilation is itself handled through an extended XSLT transformation -- the source code, being an XML document, would tell the XSLT compiler to introduce external XSLT stylesheets that contain specialized code. This code that is created would then consist not of a single XSLT document, but rather an XSLT document that contains import code for other XSLT filters. One advantage to this approach is that a number of the major XML parser designers include the ability to compile and persist XSLT as binary objects, making them much more efficient for scalability purposes. d.. Object Oriented. This goes without saying. Something that I've been playing with has been the development of object oriented XSLT filters -- you create an instance of an object, such as a Table Filter, that can take a data stream and additional elements as parameters as well as an action parameter that determines the method to be invoked: <xpo:table_filter action="display_wml_format" source="$my_stream" output="new_table"/> a.. This call would take the contents of the $my_stream variable, apply the display_wml_format in the table_filter object, then place the resulting xml into a new variable called $new_table. This might be first pass transformed into an XSLT script looking something like: <!-- in the header --> <xsl:import href="table_filter.xsl"/> <!-- in the body of the transform --> <xsl:variable name="temp_1"> <xsl:call-template name="table_filter"> <xsl:with-param name="action" select="'display_wmil_format'"/> <xsl:with-param name="source" select="$my_steam"/> </xsl:call-template> </xsl:variable> <xsl:variable name="new_table" select="node-set($temp_1)"/> a.. Of course, if no output attribute existed, then the contents from the call would go directly into the default output stream. An alternative functional form might also be possible: <xp:out>xpo:table_filter!display_wml_format($my_stream) </xp:out> a.. which would send the contents directly to the output stream. In this case, xp: is the XML Pipes native namespace, while the xpo: namespace corresponds to XML Pipe Objects. This could even be simplified further as: <xp:with object="xpo:table_filter"> <xp:out>display_wml_format($my_stream)</xp:out> </xp:with> a.. which corresponds roughly to the VB With keyword, assigning a given object as the scope of all functions for the duration of the with statement. a.. b.. Add constructs rather than create one from whole cloth. You can do a fair amount already with XSLT. If XPL is to succeed, it should add constructs that add functionality to XSLT -- it'll make it easier to adopt, make it easier to templatize, and will allow you to incorporate XSLT calls within your XPL script (the first pass transformation would simply adopt a different namespace designation for the XSLT keywords, a common enough practice). For example, it would be useful at times to include an indexed for to the for-each statement that currently exists: <table> <xp:for start="1" index="i" test="$i <= 20"> <row> <cell>{$i}</cell> <cell>{$i*$i}</cell> </row> </xp:for> </table> This would end up creating a table iterating from 1 to 20 inclusive, with the value and the square of the value in contiguous cells. Again, though this would be post processed into XSLT, which would probably have to do a structure like: <xsl:template name="for"> <xsl:param name="i" select="1"/> <xsl:param name="increment" select="1"/> <row> <cell><xsl:value-of select="$i"/></cell> <cell><xsl:value-of select="$i*$i"/></cell> </row> <xsl:if test="$i <=20"> <xsl:call-template name="for"> <xsl:with-param name="i" select="$i+$increment"/> <xsl:with-param name="increment" select="$increment"/> </xsl:if> </xsl:template> By doing this, you replace a complicated structure with a much simpler one without having to write a parser that handles the internal task of iterating. Note also the use of the XSLT bracket elements {} to handle evaluation of content into the output stream. This is essentially the same as <xp:out></xp:out>. b.. Use XPL calls for handling external objects. One of the areas that involves the biggest amount of work would be an extension that would let you communicate with external objects. By hiding it behind an xpo: namespace, you could hide the differentiation between internal objects and COM interfaces: <xp:declare_new_object name="fso" href="Scripting.FileSystemObject" type="COM"/> <xp:exec cmd="fso:createTextFile('NewFile.txt',2)" var="txtfile"/> <xp:out>$txtfile!ReadAll()</xp:out> This would create a file system object (a COM object), would execute the method createTextFile on the object and assign the handle to the $txtfile variable, which could then call the RealAll method and output the results into the output stream. c.. Pass server variables in as parameters. Much of XSLT involves parameterization of form or query string data. Variables can be declared within XP that automatically fill with the server variable if it is passed: <xp:query var="page"/> <xp:query var="item_number"/> For the query string "mydoc.xp?page=4&item_number=6" then this will be converted into: <xsl:param name="page" select="4"/> <xsl:param name="item_number" select="6"/> Since the XSLT is compiled afterwards itself into a binary, the page and item_number parameters can be set through DOM calls at some later point. Additionally, server variables such as QUERY_STRING are automatically added to the list of available parameters, so that you could use $QUERY_STRING as an expression without having to explicitly declare it. d.. Verbosity. XSLT is verbose in part because of the use of namespaces, and in part because the architecture favors the use of recursive structures over procedural ones, which in turn tends to stress template blocks that can get hideously complex. However, using a two pass architecture you can turn a significant amount of your code into either tag and attribute forms, or executable line calls. You could even create multiline script blocks using this architecture, since the code will be converted into XSLT that would be manipulatible: <xp:for index="i" start="0" test="$i < 20" output="$sum"> <xp:var name="j" init_value="0"/> <xp:var name="sum" init_value="0"/> <xp:script> $j=$j+$i; $sum=$sum+$j; </xp:script> </xp:for> While this is a little more complex that the equivalent procedural code, it's not that much worse: function sum(){ var j = 0; var sum = 0; for (i=0;i<20;i++){ j=j+i; sum=sum+j; } return sum; } These are just a few thoughts on the issue. In the main, I would suspect that if XPL can stick closely to the XSLT/XPath specifications, enhance rather than replace functionality, and work with a dual path architecture that will transform the XPL into a compiled XSLT form (a la the MS Processor object) it will make for a far more flexible language. Kurt Cagle XML Pro, Fawcette/DevX cagle@o... (360) 951-6159 ---------------------------------------------------------------------- ------ -- ---------------------------------------------------------------------- ------ -- To unsubscribe from this group, send an email to: xpl-unsubscribe@o... --- End forwarded message --- |
|
From: reid_spencer <ras...@re...> - 2002-01-31 08:38:38
|
--- In xpl-dev@y..., "Kurt Cagle" <cagle@o...> wrote:
Just a brief introduction. My name is Kurt Cagle, and I am a writer
and programmer specializing in XML related issues. I was one of the
starting writers for Fawcette's XML Magazine, and have written books
for Microsoft, Wrox, Coriolis and Sybex on XML. I'm currently working
on the XSLT documentation for the MSDN website. I'm a fair VB
programmer (I've written a book VB and web technology) but I've
basically been living, eating and breathing XML, XSLT and XML Schema
for the past three years.
I was forwarded the xpl address by Mark Wilson, and am writing to get
involved with what is happening here. I want to second his comments
that VBXML is made up of a number of developers that are dealing with
programming XML at any number of different levels -- the VB side is
very much secondary to the XML side. I would heartily recommend that
you bring the superb discussion I've seen thus far into VBXML -- I
think it would be invaluable for making XPL a viable language.
Concerning XPL, I'd like to add my two cents worth into the
discussion -- one of the things that I've been doing with Mark is
putting together an XSLT based framework, and XPL seems like a good
place to explore in attempting to put this together.
My own sense of the programming language interface that needs to be
addressed involves a number of different aspects:
a.. XLST Integration. XSLT is the programming language for XML. Any
XPL language needs to recognize this as a central tenet. As I see it,
the language should be something that can exist as a namespace
addition to XSLT, which has a basic (albeit currently somewhat crude)
mechanism for extending XSLT itself. James Clarke's XT contains hooks
for Java through a namespace, and the MSXML3 parser lets you both
create objects and instantiate existing COM objects (sort of) through
the same mechanism.
b.. Declarative vs. Procedural Programming. XSLT is fundamentally
declarative, even in its use of named templates and parameters. The
temptation to make the XPL language procedural is pretty strong, but
I would personally argue that it is one that needs to be resisted.
Procedural programs tend to encourage statist thinking, work best for
synchronous (local) communication, and can already be readily
emulated with languages like JavaScript. Any XPL language should be
largely syncretic -- it should be possible using XPL to create other
XPL programs dynamically, because one of the real strengths of XSLT
(one that hasn't been explored yet) is that XSLT allows for the
creation of code through automated processes.
c.. Multi-pass compilation. One of the things that I'm doing with
the XMLPipes framework that I'm writing is to view the XP code as
being the easier to author source code that is in turn compiled into
XSLT transformations that can be handled by existing processes. The
compilation is itself handled through an extended XSLT
transformation -- the source code, being an XML document, would tell
the XSLT compiler to introduce external XSLT stylesheets that contain
specialized code. This code that is created would then consist not of
a single XSLT document, but rather an XSLT document that contains
import code for other XSLT filters. One advantage to this approach is
that a number of the major XML parser designers include the ability
to compile and persist XSLT as binary objects, making them much more
efficient for scalability purposes.
d.. Object Oriented. This goes without saying. Something that I've
been playing with has been the development of object oriented XSLT
filters -- you create an instance of an object, such as a Table
Filter, that can take a data stream and additional elements as
parameters as well as an action parameter that determines the method
to be invoked:
<xpo:table_filter action="display_wml_format" source="$my_stream"
output="new_table"/>
a.. This call would take the contents of the $my_stream variable,
apply the display_wml_format in the table_filter object, then place
the resulting xml into a new variable called $new_table. This might
be first pass transformed into an XSLT script looking something like:
<!-- in the header -->
<xsl:import href="table_filter.xsl"/>
<!-- in the body of the transform -->
<xsl:variable name="temp_1">
<xsl:call-template name="table_filter">
<xsl:with-param name="action"
select="'display_wmil_format'"/>
<xsl:with-param name="source" select="$my_steam"/>
</xsl:call-template>
</xsl:variable>
<xsl:variable name="new_table" select="node-set($temp_1)"/>
a.. Of course, if no output attribute existed, then the contents
from the call would go directly into the default output stream. An
alternative functional form might also be possible:
<xp:out>xpo:table_filter!display_wml_format($my_stream)
</xp:out>
a.. which would send the contents directly to the output stream. In
this case, xp: is the XML Pipes native namespace, while the xpo:
namespace corresponds to XML Pipe Objects. This could even be
simplified further as:
<xp:with object="xpo:table_filter">
<xp:out>display_wml_format($my_stream)</xp:out>
</xp:with>
a.. which corresponds roughly to the VB With keyword, assigning a
given object as the scope of all functions for the duration of the
with statement.
a.. a.. Add constructs rather than create one from whole cloth. You
can do a fair amount already with XSLT. If XPL is to succeed, it
should add constructs that add functionality to XSLT -- it'll make it
easier to adopt, make it easier to templatize, and will allow you to
incorporate XSLT calls within your XPL script (the first pass
transformation would simply adopt a different namespace designation
for the XSLT keywords, a common enough practice). For example, it
would be useful at times to include an indexed for to the for-each
statement that currently exists:
<table>
<xp:for start="1" index="i" test="$i <= 20">
<row>
<cell>{$i}</cell>
<cell>{$i*$i}</cell>
</row>
</xp:for>
</table>
This would end up creating a table iterating from 1 to 20 inclusive,
with the value and the square of the value in contiguous cells.
Again, though this would be post processed into XSLT, which would
probably have to do a structure like:
<xsl:template name="for">
<xsl:param name="i" select="1"/>
<xsl:param name="increment" select="1"/>
<row>
<cell><xsl:value-of select="$i"/></cell>
<cell><xsl:value-of select="$i*$i"/></cell>
</row>
<xsl:if test="$i <=20">
<xsl:call-template name="for">
<xsl:with-param name="i" select="$i+$increment"/>
<xsl:with-param name="increment" select="$increment"/>
</xsl:if>
</xsl:template>
By doing this, you replace a complicated structure with a much
simpler one without having to write a parser that handles the
internal task of iterating. Note also the use of the XSLT bracket
elements {} to handle evaluation of content into the output stream.
This is essentially the same as <xp:out></xp:out>.
a.. Use XPL calls for handling external objects. One of the areas
that involves the biggest amount of work would be an extension that
would let you communicate with external objects. By hiding it behind
an xpo: namespace, you could hide the differentiation between
internal objects and COM interfaces:
<xp:declare_new_object name="fso" href="Scripting.FileSystemObject"
type="COM"/>
<xp:exec cmd="fso:createTextFile('NewFile.txt',2)" var="txtfile"/>
<xp:out>$txtfile!ReadAll()</xp:out>
This would create a file system object (a COM object), would execute
the method createTextFile on the object and assign the handle to the
$txtfile variable, which could then call the RealAll method and
output the results into the output stream.
a.. Pass server variables in as parameters. Much of XSLT involves
parameterization of form or query string data. Variables can be
declared within XP that automatically fill with the server variable
if it is passed:
<xp:query var="page"/>
<xp:query var="item_number"/>
For the query string "mydoc.xp?page=4&item_number=6" then this will
be converted into:
<xsl:param name="page" select="4"/>
<xsl:param name="item_number" select="6"/>
Since the XSLT is compiled afterwards itself into a binary, the page
and item_number parameters can be set through DOM calls at some later
point. Additionally, server variables such as QUERY_STRING are
automatically added to the list of available parameters, so that you
could use $QUERY_STRING as an expression without having to explicitly
declare it.
a.. Verbosity. XSLT is verbose in part because of the use of
namespaces, and in part because the architecture favors the use of
recursive structures over procedural ones, which in turn tends to
stress template blocks that can get hideously complex. However,
using a two pass architecture you can turn a significant amount of
your code into either tag and attribute forms, or executable line
calls. You could even create multiline script blocks using this
architecture, since the code will be converted into XSLT that would
be manipulatible:
<xp:for index="i" start="0" test="$i < 20" output="$sum">
<xp:var name="j" init_value="0"/>
<xp:var name="sum" init_value="0"/>
<xp:script>
$j=$j+$i;
$sum=$sum+$j;
</xp:script>
</xp:for>
While this is a little more complex that the equivalent procedural
code, it's not that much worse:
function sum(){
var j = 0;
var sum = 0;
for (i=0;i<20;i++){
j=j+i;
sum=sum+j;
}
return sum;
}
These are just a few thoughts on the issue. In the main, I would
suspect that if XPL can stick closely to the XSLT/XPath
specifications, enhance rather than replace functionality, and work
with a dual path architecture that will transform the XPL into a
compiled XSLT form (a la the MS Processor object) it will make for a
far more flexible language.
Kurt Cagle
XML Pro, Fawcette/DevX
cagle@o...
(360) 951-6159
--- End forwarded message ---
|
|
From: reid_spencer <ras...@re...> - 2002-01-31 08:37:33
|
--- In xpl-dev@y..., Mark Wilson <mark_tracey@y...> wrote: Hi Michael and XPLers I run VBXML.COM Michael, I have got someone setting up a password and login for your free subweb on VBXML.COM http://www.vbxml.com/xpl When I get those details, you or anyone else are welcome to go mad building your homepages! VBXML.COM has many many XSLT gurus in our other discussions who would LOVE to be a part of this. In fact, that's why I joined XPL - because I know that there is incredible value in this project. When you begin setting up I can pretty much garuantee you will get a BIG boost in APPLIED suggestions from people like Kurt Cagle and other VBXMLers who have already put their minds to these ideas. So, hang in there and then set up your homepage and then we'll get some momentum and growth for you. Cheers, Mark Wilson VBXML.COM Author, XML Programming with VB and ASP --------------- Message: 6 Date: Wed, 7 Jun 2000 11:47:47 -0400 (EDT) From: Michael Lauzon <ce940@f...> Subject: Re: Homepage stuff We have a home on VBXML.com, but as I don't have access at the moment to FTP or HTML editing software I can't do anything with it. Also, I haven't gotten a response back from the current owner of XPL.ORG; so let us all email him/her about the domain name. He/she can be reached at: den@g... Put in the subject of your message to him/her: XPL.ORG Domain __________________________________________________ Do You Yahoo!? Yahoo! Photos -- now, 100 FREE prints! http://photos.yahoo.com --- End forwarded message --- |
|
From: reid_spencer <ras...@re...> - 2002-01-31 08:36:54
|
--- In xpl-dev@y..., "Richard Hein" <935551@i...> wrote: I think that we better all look at these two languages, because they cross over into what we are discussing, and unless you want to reinvent the wheel, it would be foolish to ignore it. I am disapointed in the group for ignoring my messages, if that's what is going on. Maybe you are all looking at it now, and haven't had time to respond ... if so I apologize ... but I for one don't want to waste my time doing something that someone else is working on and is way ahead on, and is bound to make a formal specification and recommendation to the W3C. Isn't there any input on XFA and XMLScript? Richard A. Hein --- End forwarded message --- |
|
From: reid_spencer <ras...@re...> - 2002-01-31 08:36:33
|
--- In xpl-dev@y..., "Dan Birsan" <barsand@h...> wrote: Hi everybody, What do you say about some definition for XPL. OK I agree that XPL = eXtensible Programming Language But maybe we try to answer to some Questions! - Who is XPL? - What is XPL? - How is XPL? Any ideas so far? Thanks Dan --- End forwarded message --- |
|
From: reid_spencer <ras...@re...> - 2002-01-31 08:36:13
|
--- In xpl-dev@y..., Jonathan Burns <saski@w...> wrote: gutman@m... wrote: > Jonathan Burns wrote: > > Message passing is problematic, though. There is a clear > > difference between object method calling in C++, where the > > class is predetermined in the compile phase, and in Java > > or Smalltalk, where determining the class is part of the > > execution. > > Correct me if I misunderstand something. > In some languages, the type (class) of a variable's value > is fixed throughout its scope, while, in other languages, > the type of a variable's value can be different > at different execution points. Is this we are talking about? Yes. What I have in mind is cases such as the well-known renderinglist, in which a graphic element can act on method calls like "Draw", which are generic to all graphic element types, and also on calls like "Smooth", which belong specifically to spline curves and such. In Smalltalk, the receiver of a call can handle it directly, or else pass it up its chain of inheritance to some superclass which it belongs to. The same mechanism requires special coding to implement in C++. > Even if you meant something different, let's consider > this very problem, since it seems to be similar. > > Every normal (foobar-complete, I do not remember the term) > programming language is powerful enough to implement > any programming concept (even multiple class inheritance > can be implemented in the Turing machine language). > The only cost is bulkiness of the resultant code. > > Of course, we do not want XPL to be so weak as to be easily > (almost directly) transformed into any language. > Quite the reverse, we want XPL to be so powerful as > to be able to easily implement any concept implemented > in any language (of a wide class of them). > At least I want it to be so. :-) There will be power to spare, I think. But I think the power will show itself through the central concept of hierarchy - meaning recursion. And grammar, or regular languages, which are an intricate kind of recursion - but which have a theory behind them which contains efficient basic algorithms. Let me get back to this, when I've studied up on XSLT. > As regards our question (fixed vs variable type of a value), > my suggestion is as follows: let XPL be ready for both cases. > For instance, let it be possible, when declaring a variable, > to say if the type of its values is fixed or not > (or provide an instruction saying that all the variables > within some fragment have either fixed or variable type). OK. You know how we speak of indirect reference to data elements,via pointers. We can refer to the element as defined, or to a pointer to a choice of elements, or a pointer to a choice of pointers. I suspect that the answer we want is indirect typing. We can refer to an operation by the types it takes as defined, or by indirect types which may stand in for a choice of types, or to a choice of indirect types. We may get this implemented by operations on namespaces. Maybe. > If the destination language assumes only fixed types, > and an XPL program employes variable types, > the resultant code just will be more bulky. > When using XPL, it is the user who decides whether > to employ variable types. The cost is known. As with C pointers. Yeah. > > Variable scope and lifetime also present some problems. > > We'll need to do proper comparisons between the classic > > scripting languages (Tcl, Perl, Python, to name the obvious) > > to make certain we can handle these by tree-transformation. > > This problem seems to be similar. > As soon as the scope and lifetime of an XPL variable > are determined (for an XPL program), it is the task > of the transformation procedure to provide the corresponding > resultant code which can be either concise or bulky, > depending on the destination language. Dynamic namespaces again. > > I think the lesson we'll learn, if we don't anticipate it, > > is that XPL applications will often be object-oriented. > > A like this conclusion. :-) > > > That is, each section will be available through an interface, > > and call code in other sections by message-passing. AND, > > a section when it calls another, will be unaware whether > > this other is local or remote. > > Hmm... I do not think this concerns XPL itself. > When a user writes an XPL program, he/she may suppose that > the whole program will be executed on a single machine. > Later, if the code will be split into different parts > (e.g. into server and client ones), it is again the task of the > transformation procedure to provide correct resultant codes. > And only at this step the message-passing arguments start > playing their role. Some posts back, I was trying out the idea of variables ascontainers, therefore as documents. But of course, it's a virtual container, if you can reach in and get stuff out. What you're suggesting, I think, is that a variable is a virtual container - like a typed URL, with read/write capability. The type of the container, and its oontents, are independent of its location - whether local or remote. Actually, in this sense, a Web page is a virtual document. To look at it, you can't tell whether it is from your site or another (the URL has to tell you that), or whether it was just sitting there as data, or constructed on the fly by a CGI program. Hmmm. > As an example, consider the following hypothetical XPL code: > <declare variable="x" class="someClass"/> > <if> > <condition> > <equal> > <property name="someProperty" of="x"/> > <constant value="someValue"/> > </equal> > </condition> > <then> > <assign> > <property name="someProperty" of="x"/> > <constant value="anotherValue"/> > </assign> > <etc>...</etc> > </then> > <else> > <etc>...</etc> > </else> > </if> > > Suppose that the developer decides that the whole code > should be executed on the client side except the "then" part > which should be separated into a server module. > A problem seems to arise: this part uses the "x" variable > which is declared within the client part. > No problem! The transformation procedure will create an > additional bridge code between the server's and client's "x"s > so that, whenever the server's "x" is changed, the client's "x" > also changes appropriately (and vice versa, if need be). > This'll date me. I remember when there was much fuss about"relocatable code" and how to compile it. The point was, that the traditional machine code was compiled with absolute machine addresses hardwired in. It only ran correctly whem it was located at a specific place in memory. Then along came relocatable code, which could run no matter where it was placed. How? Either indirect addressing, or base registers, which are a machine-level form of indirect addressing. The exact same trick has been done lately, in the form of relative URLs on Web pages. A site can run on my machine; then I FTP every page to a remote host, and all the links still work there. You're talking about automatically switching a variable from local to remote reference. We're near the mother lode here, I think. > > It is straightforward to translate Java control flow > > to C++ control flow. The syntax is just about the same > > anyway. > > > > But, Java's dynamic class binding will not translate to > > C++ static binding, without the creation of some kind of > > object tag system for the C++. This is a problem. > > You have already provided a solution: just make > the transformation procedure to create (or use) > an object tag system in this case. > Another case of indirect typing. Stone the crows. This is getting interesting. Thnaks for a most enlightening set of suggestions. Gives me a lot to think about. Jonathan In evolutionary terms, we're standing still, while doors get smarter and smarter. You see where this leads. --- End forwarded message --- |
|
From: reid_spencer <ras...@re...> - 2002-01-31 08:35:15
|
--- In xpl-dev@y..., Michael Lauzon <ce940@f...> wrote: Jonathan, Neither am I in that department. :) Well, the person did want money...just hasn't told me how much. On Thu, 8 Jun 2000, Jonathan Burns wrote: > Michael Lauzon wrote: > > > We have a home on VBXML.com, but as I don't have access at the moment > > to FTP or HTML editing software I can't do anything with it. Also, I > > haven't gotten a response back from the current owner of XPL.ORG; so > > let us all email him/her about the domain name. He/she can be reached > > at: > > > > den@g... > > > > Put in the subject of your message to him/her: > > > > XPL.ORG Domain > > > > With respect, Michael, this kind of approach is better done > by one person than several. If this person is slow to respond, > confronting him/her with several different emails to answer > won't speed him/her up. > > Be patient, find out what he/she wants. If it's money, I'm > afraid I am NOT the person to see right now. > > Jonathan > > > > -------------------------------------------------------------------- ---- > Take your development to new heights. Work with clients like Dell and > pcOrder. Submit your resume to jobs@l... Visit us at > http://click.egroups.com/1/4358/1/_/809694/_/960418962/ > -------------------------------------------------------------------- ---- > > To unsubscribe from this group, send an email to: > xpl-unsubscribe@o... > > > > Michael http://www.geocities.com/SiliconValley/Way/9180/ 'Eat, drink, and be merry, for tomorrow you may work.' --- End forwarded message --- |
|
From: reid_spencer <ras...@re...> - 2002-01-31 08:34:46
|
--- In xpl-dev@y..., gutman@m... wrote:
Jonathan Burns wrote:
> It's terribly tempting to suppose that there is "just one"
> procedural language. I think that for control flow, it is
> nearly the case. Everyone has an If, a Do-While, and a
> Call ... maybe a For, maybe a Switch-on-Case, but we could
> do without these in a pinch. Try/Catch is left as an exercise
> for the reader :-)
Yes. At this point, the only we need to do
is to choose a good XML syntax.
> Message passing is problematic, though. There is a clear
> difference between object method calling in C++, where the
> class is predetermined in the compile phase, and in Java
> or Smalltalk, where determining the class is part of the
> execution.
Correct me if I misunderstand something.
In some languages, the type (class) of a variable's value
is fixed throughout its scope, while, in other languages,
the type of a variable's value can be different
at different execution points. Is this we are talking about?
Even if you meant something different, let's consider
this very problem, since it seems to be similar.
Every normal (foobar-complete, I do not remember the term)
programming language is powerful enough to implement
any programming concept (even multiple class inheritance
can be implemented in the Turing machine language).
The only cost is bulkiness of the resultant code.
Of course, we do not want XPL to be so weak as to be easily
(almost directly) transformed into any language.
Quite the reverse, we want XPL to be so powerful as
to be able to easily implement any concept implemented
in any language (of a wide class of them).
At least I want it to be so. :-)
As regards our question (fixed vs variable type of a value),
my suggestion is as follows: let XPL be ready for both cases.
For instance, let it be possible, when declaring a variable,
to say if the type of its values is fixed or not
(or provide an instruction saying that all the variables
within some fragment have either fixed or variable type).
If the destination language assumes only fixed types,
and an XPL program employes variable types,
the resultant code just will be more bulky.
When using XPL, it is the user who decides whether
to employ variable types. The cost is known.
> Variable scope and lifetime also present some problems.
> We'll need to do proper comparisons between the classic
> scripting languages (Tcl, Perl, Python, to name the obvious)
> to make certain we can handle these by tree-transformation.
This problem seems to be similar.
As soon as the scope and lifetime of an XPL variable
are determined (for an XPL program), it is the task
of the transformation procedure to provide the corresponding
resultant code which can be either concise or bulky,
depending on the destination language.
> I think the lesson we'll learn, if we don't anticipate it,
> is that XPL applications will often be object-oriented.
A like this conclusion. :-)
> That is, each section will be available through an interface,
> and call code in other sections by message-passing. AND,
> a section when it calls another, will be unaware whether
> this other is local or remote.
Hmm... I do not think this concerns XPL itself.
When a user writes an XPL program, he/she may suppose that
the whole program will be executed on a single machine.
Later, if the code will be split into different parts
(e.g. into server and client ones), it is again the task of the
transformation procedure to provide correct resultant codes.
And only at this step the message-passing arguments start
playing their role.
As an example, consider the following hypothetical XPL code:
<declare variable="x" class="someClass"/>
<if>
<condition>
<equal>
<property name="someProperty" of="x"/>
<constant value="someValue"/>
</equal>
</condition>
<then>
<assign>
<property name="someProperty" of="x"/>
<constant value="anotherValue"/>
</assign>
<etc>...</etc>
</then>
<else>
<etc>...</etc>
</else>
</if>
Suppose that the developer decides that the whole code
should be executed on the client side except the "then" part
which should be separated into a server module.
A problem seems to arise: this part uses the "x" variable
which is declared within the client part.
No problem! The transformation procedure will create an
additional bridge code between the server's and client's "x"s
so that, whenever the server's "x" is changed, the client's "x"
also changes appropriately (and vice versa, if need be).
> It is straightforward to translate Java control flow
> to C++ control flow. The syntax is just about the same
> anyway.
>
> But, Java's dynamic class binding will not translate to
> C++ static binding, without the creation of some kind of
> object tag system for the C++. This is a problem.
You have already provided a solution: just make
the transformation procedure to create (or use)
an object tag system in this case.
--
Alexander E. Gutman
--- End forwarded message ---
|
1 message has been excluded from this view by a project administrator.
