[exprla-devel] Re: [XPL] Direction and purpose of XP

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

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