RE: [xsl] XSLT for Mashups

["Alex Clark" <alex@xxxxxxxxxxx>]

> 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

I couldn't agree more.  Our product evolved over several years and at the
time of creation we didn't have the vision of extending XSLT to use as a
mashup language.  I specifically said I didn't want to reinvent XSLT while
developing the mashup.   I wanted a simple XML configuration language for
our mashup product.  As time went on, customers wanted more features and
would use the product in creative ways that we didn't imagine.  

Once I had the realization that our original mashup configuration files had
become a full programming language similar to XSLT, I started thinking, "why
not extend XSLT to support multiple inputs of any type to many outputs of
any type?"  Then information in databases, XML documents, web services, RSS
feeds, web sites, ERP systems, etc. could be brought together and processed
by the templates, and the results could be returned as XML, and/or used to
update databases, call web services, etc.  After all, isn't this exactly
what a mashup does? 

Reviewing the Open Mashup Alliance and EMML really solidified my belief that
there should be a standard language for mashups.  This allows people to
choose the best vendor platform without being locked in.  EMML has chosen to
create its own tags that are similar to XSL but different enough to add
confusion and reinvent the wheel.  Extending the XSL standard seems like a
better solution.

My personal preference would be to see something ambitious like an XSL 3.0
specification that supports the multiple inputs, outputs, and expressions
that facilitate this type of information processing.  A second option could
be a separate standard that defines custom extensions to the existing XSL
standard.  This option is not optimal because, as XSL changes over time, the
other specification may get out of sync.  In addition, the two
specifications would be very similar, just differ on additional tags and the
support of the varying input / output types.  Also, the first option would
open up more processors on the market and place greater functionality in the
hands of developers.  I suppose it sounds strange that I'm inviting the
industry to create more competition to our product but may the best product
win!  :)

We've gotten a lot of positive feedback on our product and it has been very
useful to many developers and organizations.  I believe the general
community would benefit by having a familiar standard and a wider offering
of products that support that standard.  I would be very happy to make
significant contributions to such a standard (or lead the thing if I need
to!).  The understanding I'm trying to get right now is:

Does the community feel such a standard has value?

Does the community feel an XSL 3.0 approach is best or would prefer to
create a new standard based on extensions to the existing XSL specification
(i.e. keep them separate)? 

What is the best way to move forward on this standard?

Cheers,

Alex