RE: [xsl] XSLT for Mashups

["Michael Kay" <mike@xxxxxxxxxxxx>]

So far, it seems to me that the language described on your web site is
essentially equivalent to XSLT plus a number of extensions (access to
information about the HTTP request, access to SQL databases, invoking web
services, email, libraries of functions, multithreading, transactions,
try/catch). These extensions correspond closely to extensions that people
have implemented, or have discussed implementing, within the extensibility
framework offered by the XSLT language. In other words, I think you could
convert your processor to being a conformant XSLT 2.0 processor with
conformant extensions. You may discover that you've left out quite a few
things that are needed in a conformant processor (grouping, regular
expression support, multiple outputs?), and that your users will want too.

I think you'd be serving the community far better (and therefore, your
business would thrive better!) if you delivered the "added-value" features
of your product on top of standard XSLT, and I don't see anything in your
language specification that makes it impossible to achieve this.

Some of the features you add, like try/catch, will probably make it into
future versions of the core language, others (like access to SQL databases)
will probably be left to third parties to define. There's a lot of interest
at the moment in defining features for access to web services, but it's
happening outside the W3C working group.

It's my experience that implementing a specification produced by a standards
body can sometimes have frustrations (when you think you could have designed
it better yourself, or when you have to add features that don't seem
necessary) but there are several big compensations: you get a specification
that has had far more thought put into it that you would be likely to expend
on your own specification; and you get access to a user community that is
already sold on the language you are implementing.

Even better, join in the standards activities that are setting the future
direction. This again gives your users confidence that they aren't going out
on a limb, and it gives you a forum in which your ideas can be subjected to
critical review before you spend money implementing them, which makes it
much more likely that what you implement is good.

Regards,

Michael Kay
http://www.saxonica.com/
http://twitter.com/michaelhkay 
 

> -----Original Message-----
> From: Alex Clark [mailto:alex@xxxxxxxxxxx] 
> Sent: 03 March 2010 02:33
> To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
> Subject: [xsl] XSLT for Mashups
> 
> Hello all,
> 
> I am the CTO of Bit Stew Systems and we offer a mashup 
> technology that is loosely based on extending XSLT, and 
> leverages the capabilities of XPath 2.0 across any data 
> source.  We've created a mashup language that we call Mix, 
> which has similar syntax and constructs to XSLT, and combined 
> it with powerful capabilities for discovering and using the 
> vast amounts of information on the Internet and the 
> Enterprise.  This approach has worked very well for us 
> because developers that are already familiar with XSLT and 
> XPath can create mashup solutions right away.  
> 
> Mashups are becoming an increasingly important part of the 
> technology industry for data integration, transformation, and 
> analytics.  The Open Mashup Alliance is in the early stages 
> of establishing a standard XML-based mashup language called 
> EMML.  However, it seems their approach reinvents the wheel.  
> They have constructs such as if, for-each, etc. that are 
> already defined in XSLT but they've changed them to be just 
> different enough to add confusion.
> 
> It seems to me that a natural progression is to extend XSLT 
> from generally one input (XML) and one output (XML, HTML, 
> etc) to include numerous input sources of varying types to 
> numerous output targets.  This type of approach would allow 
> the XSLT language (XSLT 3.0?) to be used as an industry 
> standard language for enterprise mashup solutions.
> 
> I believe it would make more sense to extend XSLT and add 
> expressions that support building mashups rather than to 
> define a new language with similar constructs.  This would be 
> a better standard for the technology community because of the 
> familiarity many have with XSLT and the availability of 
> processors in the market.  Plus, learning yet another 
> language is a burden on developers-especially when a 
> perfectly suitable one already exists.
> 
> I've included a simple example that illustrates some of the 
> constructs we've added to XSLT that enables the language to 
> be used for Mashups.  The example below fetches data from two 
> sources (a REST service and a relational
> database) and returns an XML document.   
> 
> I'd be very interested to hear everyone's thoughts about 
> leveraging XSLT to create an industry standard mashup 
> language.  More examples can be found:
> http://www.bitstew.com/docs/mix/stl/index.html
> 
> Thank you all for your thoughts,
> 
> Alex Clark
> 
> <!-- Begin contrived example -->
> <mix:template xmlns:mix="http://bitstew.com/schemas/1.0/xml-template";>
>     
>     <!-- Define our JDBC Source -->
>     <mix:include href="settings.xml"/>
>     
>     <MatchingCustomers>
>         
>         <!-- Get a list of customers from a partner's web 
> service (REST service that returns XML). -->
>         <mix:xml-source name="theirCustomers"
> url="http://bitstew.com/example/getCustomers?partnerID={$ourID}"/>
>         
>         <!-- Get the list of customers that have our parnter's ID. -->
>         <mix:query name="ourCustomers" 
> source="customerDB">select * from customer where partner_id = 
> {$partnerID}</mix:query> 
>         
>         <!-- For each of our customers -->
>         <mix:for-each select="$ourCustomers">
>         
>             <!-- If the customer ID matches the partner's 
> customer ID, then return the match. -->
>             <mix:if test="./partner_id = {$partnerID}">
>                 <Customer id="{./id}">
>                     <Name><mix:value-of select="./name"/></Name>
>                 </Customer>
>             </mix:if>
>             
>         </mix:for-each>
>                 
>     </MatchingCustomers>
>     
> </mix:template>
> <!-- End contrived example -->