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(_at_)bitstew(_dot_)com]
Sent: 03 March 2010 02:33
To: xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
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 -->
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail:
<mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--