SourceForge.net: Project Info - google-xjaxslt
AJAXSLT is an implementation of XSL-T in JavaScript, intended for use in fat web pages, which are nowadays referred to as AJAX applications. Because XSL-T uses XPath, it is also an implementation of XPath that can be used independently of XSL-T.
Um. SWEET!!!!
Just one thing though...
Did you really 'just have' to find a way to throw AJAX into the name? By doing so guess what happens when functional programming languages like Haskell and Lisp/Scheme become just as common and available in the browser as Javascript, XMLHTTP, an XML parser, XPath(some), and a DOM implementation are today?
While you ponder this...
Quite frankly I fear the day that Jesse James Garrett suddenly awakens to realize there's an un-siezed acronymic opportunity in the continued drive towards a Lisp-like functional programming paradigm to dig even further into our computing past to exploit the good, untarnished, time-tested, 'never met any type they didn't like' languages like Scheme(a Lisp dialect for those in the (un)know), Haskell, and (of course) (Common) Lisp combined with an objectified schema and XML syntax or, more likely than syntax, data source to be processed via the above language mechanisms.
Haved you pondered enough to imagine the result?
Just in case let me give you a 'hint' with this potential brain-twister in the making:
ASynchronous Scheme, Haskell, and Objectified Lisp Extensible Markup Language
While AJAX is not my favorite acronym on this planet I somehow find myself in 10 years longing for the "good ol' 'AJAX' acronym days" when we were free from finding ourselves referencing 'ASSHOLEML' in a near Diety-like golden calf kind of way... Actually, kind of in the same way 'AJAX' seems to be regarded among some circles... ;)
Lets hope and pray that day never comes (or is it already here from an AJAX standpoint? Hmmmmm, we may be closer to fulfilling Old-Testament Bible prophecies than we realize. But that would only be something to worry about if we were living in Old-Testaments times I guess. Nevermind, worship your golden AJAX statues all you want... I think we all die via some sort of BIG-GIGANTIC fire or something (for reasons I never really quite understood actually (e.g. the Old-Testamenters were worshiping Golden Calfs but it never really says what we would be doing wrong and as such justified to fry for our wrong doings... Then again I've never really been much of a Bible scholar so who knows, maybe it does and I simply don't care enough to look it up... Uh oh, that would be a good reason to burn right there. Yikes!!! Wheres my Bible!!!! I aintz' readyz' to burnz' awayz' just yetz':)
While I try to talk God out of 'Yet Another Reason To Just Put Me Out Of Your Misery' please enjoy this rendition of... Oh wait, I think I'm good....
Huh, wierd... Thought for sure that one was 'the one' that would do me in... Guess not... Sweet!
So in the mean time I hope to play with this new little toy/gift ASAP as this has the potential to really change the landscape fairly quickly and quite dramatically, especially given the popularity of the AJAX approach to client-side browser-based application development. If this was a project from an average joe such as myself who put this together and posted it on SF I would be leary to put too much emphasis on the potential impact. But this is Google... I think it would be safe to put some trust into the idea that Google will be around for a while and willing to continue with its development and ongoing support (even from a community support standpoint at least the company who sponsored its development has a pretty good chance of being in business this time next year and probably even a year or two after that ;))
Unlike an average joe app this 'IS' something that should be considered 'EXTREMELY' monumental from a browser client application development standpoint as it has given the development world an 0.1 release of an XSLT 1.0 processor that will run on any browser that offers Javascript support (I didn't see a version right away... anyone know which version this is based/relies on?) and has such support enabled. All 'yeah but Safari/KHTML doesn't offer XSLT via script and Opera at all' are no longer valid concerns. Well, I guess that statement should be backed away from for a bit until such time that more is learned in regards to what future element/attribute/function holes will be filled.
In regards to this please note that at first glance through the code I've noticed that XPath is missing namespace support. Apparently, however, thats the only thing keeping it from being considered XPath 1.0 compliant -- although its a fairly significant piece and quite limiting as far as implementing an existing library/base of stylesheets and even more so an issue when it comes to using namespaces within the data-centric XML files. No doubt that without namespace support all elements will become part of the 'pseudo' default namespace and as such there will be no way to clearly distinguish similar XML infosets from one another.
A perfect example that is something in heavy use of namespace capability is XML data feed formats such as Atom and RSS. So using the same stylesheet to process both might prove to be a bit difficult although at this stage of the game I am unsure just how much 'crossover' element usage becomes an issue in regards to how each would be output to the browser and as such require seperate templates to match against during processing. However, labeled as a 0.1 release it would seem there is plenty of room to find support for namespaces sometime in the near future. Lets hope they do!
In regards to whats missing in XSLT? Well, that list is a significant level of magnitude higher and a little bit strange (although in thinking a bit deeper I can understand why things have panned out this way in regards to which instruction elements to provide support for first and which ones could wait) in regards to offering support for certain elements but not others.
Directly from the source code, the following snippets suggest in one form or another there is no current support:
case 'decimal-format':
alert('not implemented: ' + nodename[1]);
break;
case 'fallback':
alert('not implemented: ' + nodename[1]);
break;
<!-- MDP:Comment - Why this would not be implemented in an 0.1
release seems a bit strange as this would at least allow the
ability to write solutions that could implement a temporary fix
while support for the current list of non-supported instruction
elements move forward in development. The key point in this
argument is doing so would have allowed quick and dirty solutions
to be implemented (even if it only contained comments that would
inform others using these stylesheets that 'the current state of
AJAXSLT version 0.x does not support the xyz instruction element
as of yet. As a work around comment out any 'xyzpdq' elements
within your XML infosets such as to avoid an errors being thrown
and the transformation interrupted prematurely' or something like
this.
None-the-less its tough to complain when you are handed even a
partially implemented client-side XSLT solution in which enables
all current javascript-enabled browsers the ability to gain at
least some of this functionality. Thanks Google! -->
case 'import':
alert('not implemented: ' + nodename[1]);
break;
case 'include':
alert('not implemented: ' + nodename[1]);
break;
case 'key':
alert('not implemented: ' + nodename[1]);
break;
case 'message':
alert('not implemented: ' + nodename[1]);
break;
<!-- This one could very easily have been implemented if not to
simply have added a 'stdoutLog[]' array in which would contain
each message output during the transformation to then iterate
through and print to the screen upon completion of the
transformation. Obviously this would be quite easy to do and as
such if this is not something they plan to implement I will
quickly write it and make it available on this blog. -->
case 'namespace-alias':
alert('not implemented: ' + nodename[1]);
break;
case 'number':
alert('not implemented: ' + nodename[1]);
break;
case 'otherwise':
alert('error if here: ' + nodename[1]);
break;
<!-- not even sure what is meant by 'error if here:' maybe it
will make more sense if I were to purposely invoke the associated
alert? I'll try and test this in the next few days and if it
makes more sense afterwards I will let you know -->
case 'output':
// Ignored. -- Since we operate on the DOM, and all further use
// of the output of the XSL transformation is determined by the
// browser that we run in, this parameter is not applicable to
// this implementation.
break;
case 'preserve-space':
alert('not implemented: ' + nodename[1]);
break;
case 'processing-instruction':
alert('not implemented: ' + nodename[1]);
break;
case 'sort':
alert('error if here: ' + nodename[1]);
break;
case 'strip-space':
alert('not implemented: ' + nodename[1]);
break;
case 'when':
alert('error if here: ' + nodename[1]);
break;
case 'with-param':
alert('error if here: ' + nodename[1]);
break;
<!-- while 'param' is not completely dependent upon 'with-param'
the converse is not true ('with-param' must match up to a 'param'
element within the matching template using a comparison of 'name'
attributes to test for equality. If none is found a 'param' element
with the name(s) and value(s) of the 'with-param'(s) will not be
created and therefore available to the template in current process.)
When found within a stylesheet the only "usual" exception to
a 'param' being non-dependent on a 'with-param' of the same name
passed via the apply-templates or call-template instruction elements
is when a parameter is passed to the transformation as part of the
processors creation and implementation. The 'param' elements
contained before the first following-sibling 'template' element are
considered global and can either be set via the above mechanism or
can have a default value set within the 'select' attribute, in
single quotes when refering to a sequence of characters as opposed
to an element contained as part of an XPath statement. While
technically this can be set by setting the value of the actual
element to any string value (e.g. <xsl:param name="foo">bar</xsl:param>)
it is not a method that is recommended, especially by the likes of
the 'Big-5' in David Carlisle, Dave Pawson, Michael Kay, Wendell
Piez, and/or Jeni Tennison. [1] The short answer as to the reason
has to do with the creation of a text() node when set as
the 'param's string value as opposed to the 'select' attributes value
set between single quotes which will simply create a string value
that can be accessed. A further explanation as tp why this is an
important distinction can be found on Dave Pawson's XSL FAQ found at
http://dpawson.co.uk/xsl/index.html
[1][Actually, I really should begin to call this the big 6 as when I
first started refering to this group as the big-5 Dimitre was
extremely busy with starting his career at Microsoft and as such
disappeared from the scene for a little while only to emerge in a
very big way again over the last 8 months. (NOTE: I could even up
this to 7 with Colin Paul Adams making a definite mark as one of the
top community experts with the creation of his XSLT 2.0 processor
project.)]
-->
TrackBack URL for this entry:
http://www.xsltblog.com/xslt-blog-mt/mt-tb.cgi/875