Web Feeds, Mashups, AtomicXML, AIM Pages and ModuleT: Which of these things is not like the other?

Answer: Every single one of them (but that's a *GOOD* thing!)

What follows is a reprint of a post to my blog on XML.com that will hopefully help make more sense as to why I believe you folks here in the land of Dev.AOL might find interest in making the connections in a way that will (hopefully!) make more sense.

NOTE: Why not just link to the original post? That's a good question, and the answer is simple: Because of the *love* I have in my heart for each and every one of you, I would rather save you the time, effort, and energy *wasted* by having to make Yet Another Click just to read something I could have just as easily copy/pasted into the body of this post.

You're not gonna get all teary eyed on me, are ya? Not that I would blame you, or anything, and instead just wondering if you would like for me to grab you a tissue?

You're, Welcome! ;-)

So while you pull yourself together, one thing worth noting: As specified below, ModuleT is something in which you are going to be hearing about *LOTS* from my neck of the woods over the coming days and weeks. So please stay tuned! :D

And now without further adieu,

So last weeks “Open Source XML” post was a complete flop — well, that’s not true, as it forced me to think about and work on another project of which the code is now in good enough shape to be considered usable, and as the next few days continue forward and I am able to finish up a few higher priority items, I plan to spend some more time on this project as to connect it back into the AtomicXML-foundation (which is where I pulled the initial code base to then extend from) that I have been sporadically working on for the last three years, to then begin integration of the AspectXML code base, pulling things all together into the Xameleon processing engine.

I’ve moved a good portion of the code base from ExtensibleForge.net into a Google Code-based project @ http://code.google.com/p/extf/. This now includes the Extf.Net.Base library (which is an early implementation of the Atom Publishing Protocol > Sylvain and I, using Amplee as our API-guide, are working on bringing this same library in sync with the latest (final? seems possible) v0.13 draft of the APP spec.  However, with higher priorities at the moment, it will be next week before much progress is made on this particular section of the repository.

That said, as mentioned above, in the midst of last weeks misguided attempt at integrating Saxon on .NET with Gardens Point Ruby.NET, I began thinking about some code I began developing a while back that, in essence, uses a declarative approach to developing an ASP.NET-based application — those declarations coming in the form of Atom feeds which reference modularized data templates that use more Atom feeds as a form of storing, indexing, and versioning data and/or content and/or both and/or something else all together.

Now you might be asking why on earth you would want to do something like this, of which the answer is pretty simple,

Because you can. ;-)

Okay, not really the reason nor the answer, though the fact that you *CAN* do this — in essence, breaking apart data/content, layout, and style into a modularized containers that can then be mapped against a layout definition file (yep, in the form of an Atom feed ;) to then be output in any format you might choose — presents an interesting opportunity for not only breaking down the complexities of any given web page, application interface, or etc… into easier to manage pieces, but it also allows you to do some cool things such as allowing people to subscribe to your site, or application, or whatever, to then gather and render the various feeds referenced in the files into whatever particular format they might prefer.

Of course, if I could simply subscribe to an application, or a web site, or whatever, via something as simple, straight forward, and increasingly ubiquitous as an Atom feed, to then allow the ability for anyone to then render this for local consumption, then the notion of using this same strategy for deployment of any given ( … ) in a more controlled environment (e.g. a decentralized base of server farms (EC2 + In-House + etc… anyone? ;) would obviously be just as practical, and just as straight forward.

Now add to the mix something that hasn’t been talked about much as of late (something I both hope, as well plan to help change), and maybe you will see why a simple system such as this presents a whole new world of ideas and possibilities,

That something?  LiveClipboard.

Not enough data to see where I’m going with this?

How about: Copy/Paste/Deploy?

Still not enough?

How about,

• I visit [website A] and really like the theme, and it just so happens that the developer of this site has added a LiveClipboard icon somewhere on the page that suggests the ability (and provides a license that allows you to do so freely) to [copy the theme] which just so happens to be in an [Atom feed] that contains references to the various [modularized] [microformat layout definitions] in which can easily be rendered into [any other supported output] such as XHTML, XAML, XUL, and/or etc… 
• I [right-click] the [LiveClipboard icon], click “[Copy]”, then navigate to the [site and/or application and/or etc]… that I would like to apply this theme to, [right-click] another [LiveClipboard icon] that just so happens to have built into it the ability to then take the [Atom feed] contained on my clipboard, access all of the [referenced resources], access the [Atom feeds] that contain the data that I would like rendered, and
• *[WHAMO]* >>  It all now makes sense, now doesn’t it?!
• [Dear God], I hope so. ;-)
  

Of course, somebody out there has just made the statement: “Uh, you just stole that idea from Yahoo! Pipes!” to which my reply would be two-fold,

 * You’ve never heard of Unix, have you.
 * While I make no claims of invention (if not obvious, this is what today is called a mashup, yesterday was called code reuse, the day before that called componentized software development, and the day before that? Common Sense ;) :D), as mentioned above, this is something I’ve been publicly working on for quite some time (those who know about this will probably suggest I’ve been working on it for *TOO* long, if truth be told ;), so while I believe Yahoo! Pipes is incredibly cool, the inspiration for this project is a list of folks, technologies, and so forth that runs for miles, and miles, and miles, and years, and years, and years.
 * In short: This is just the same old thing as two years ago, implemented in just a slightly different format than was last years model such as to make it bright, and shiny, and “new” all over again.

Oh the wicked games we play to fool ourselves into believing the things that we do.  < Another topic, for another time ;)

So, with all of this, while there is a considerable amount of code that has already been developed (and is publicly available if you know where it is you should look), what I chose to do with this first round is to simplify, simplify, simplify.  There are a couple of reasons for this,

1) Not all of the code that has been developed is really all that useful for more than a handful of things, and makes things much more confusing by leaving it in place.

2) As of late, I have been getting to know (quite intimately!  more on that in the coming days and weeks) a wonderful new microformat called ModuleT, developed and made available for use by anyone, anywhere, royalty free by the good folks over at AOL.

3) AOL is a *BIG*, influential *Internet* company!

4) I believe *HEAVILY* in reuse.

5) But only if that reuse makes sense for the application in question.

6) In regards to AtomicXML, integration of ModuleT makes a TON of sense!

7) AOL is a *BIG* company in whom has the ability to reach an Internet audience that is both far and wide.

8) Can you see where I’m going with this?

9) (Please say yes. ;)

So with this understanding (hopefully!) firmly in place, lets take a look at what I am referring to by *SIMPLE*

http://extf.googlecode.com/svn/trunk/Xameleon.Asp.Net/

The above link will present a directory with two files and a directory.

Web.config
default.omx
workspace/

I mentioned above this was an ASP.NET-based application.  So you might now be wondering where on earth the Default.aspx (or similar) file is.  The answer:  There isn’t one.  So, I guess I kinda lied about the ASP.NET portion of this, but its a lie by technicality, not by a desire to confuse or mislead.  Technically speaking, there is no need to implement your typical ASP.NET script — That’s all handled by a redirect of the various HTTP requests to a custom handler that will then take things over from there.  That doesn’t mean you can’t implement your typical ASP.NET script, and instead, unless you absolutely feel that you can’t get by without it, everything is handled for you automagically.  The only thing you need to worry about is putting into place the default.omx file which, as you may have already discovered by now is nothing more than a — you guessed it — an Atom feed that specifies the various CSS, Javascript, and other necessary resources to be included in the output, to then point at the various modularized data and/or template files (again, nothing but simple Atom feeds with the modularized data/templates contained inside of the ‘content’ element) that are then processed by an XSLT 2.0 transformation file (more on that in a separate post), the various references to external data (Atom feeds) accessed, to then be woven together with the modularized templates and output in the format specified.

But let’s not get too far ahead of ourselves.  I mentioned simple, so lets focus on simple.

Inside of the Web.config file you will find a number of elements/values that should make things more obvious as to what’s taking place. 

• The key to what follows comes in the ability to run an XSLT 2.0 transformation, of which can be any given XSLT 2.0 (or 1.0, for that matter, but the now and the future is 2.0, and the capability exists, so the plan is to use the right tool for the right job, in this case that tool being XSLT 2.0-based transformation files, transformed courtesy of, what else, but Saxon on .NET :D.) you might want to specify.  To set this value, locate the /configuration/appSettings/add[@key = ‘baseTemplate’] and change @value to the desired XSLT. 
• You can also set the value of any necessary parameters to be passed into the transformation.  Please see the embedded comments for the specific details as how this works.
• The final piece of this comes in the form of the /configuration/system.web/httpHandlers/add elements.  In short, what you are specifying is that any requests for *.omx and *.atom files should be passed to the Xameleon.HttpHandler class for processing.

The contents of the Web.config file

<?xml version=”1.0″?>
<configuration>
    <appSettings>
        <!–
            DOC:SETTING AN XSLT PARAMETER
              To pass a parameter key name and value to the transformation process,
              simply add a key name and value using the “add” element as outlined below.
              The key name should use the prefix “xsltParam_”.  When the transformation file
              is compiled, the name of the parameter will be set to what follows after
              “xsltParam_”.  So, for example the value of “xsltParam_base” will be passed
              into the transformation file with the parameter name “base”.  If you would like
              to use a prefix other than “xsltParam_”, uncomment the “xsltParamKeyPrefix” key
              and change its value to the prefered prefix.
            /DOC:SETTING AN XSLT PARAMETER
        –>
        <!–<add key=”xsltParamKeyPrefix” value=”xsltParam_” />–>
        <add key=”xsltParam_xml.base” value=”http://localhost/” />
        <add key=”baseTemplate” value=”/workspace/xslt/base.xslt”/>
    </appSettings>
    <system.web>
        <httpHandlers>
            <add verb=”GET,HEAD” path=”*.omx” type=”Xameleon.HttpHandler”/>
            <add verb=”GET,HEAD” path=”*.om” type=”Xameleon.HttpHandler”/>
            <add verb=”GET,HEAD” path=”*.atom” type=”Xameleon.HttpHandler”/>
        </httpHandlers>
        <authentication mode=”None”/>
        <customErrors mode=”Off”/>
        <compilation debug=”true” batch=”false” defaultLanguage=”c#” />
        <trust level=”Full”/>
    </system.web>
</configuration>

That’s it?

Yep — That’s it.  Well, actually that’s not true.  At this stage of the game there is the need to go into the IIS MMS Snap-In and configure the mappings for .omx, .om, and .atom files to be initially handled by the ASP.NET isapi extension as well as to register these same extensions with the proper mime-types (IIS will only serve requests for files with registered mime-types.)  I need to write a setup script to properly handle this, but at the moment, this is something that must be done manually.  It’s a simple process, something of which plenty of documentation can be found on MSDN.  In other words, at the moment, going into the details of setting up IIS to proper serve and handle the various file extensions is beyond the scope of this post, something that is already FAR to long as it is.

So, to the demo.  Please keep in mind: The demo results in what seems to be a blank screen of nothing.  If you view source, you’ll notice that, in fact, the XHTML framework is in place, and I simply need to spend a few more minutes adding a few Atom-feeds to the mix for rendering a simple, straight-forward, feed-aggregator/mashup. 

Also, given that this is the first of what will be *MANY* related posts, articles, and other forms of documentation, I wanted to avoid the need to go into the details of the inner workings of the modularized templates.  As such, I purposely chose to remove the content and replace it with a TODO comment (to see what I am refering to, please access http://extf.googlecode.com/svn/trunk/Xameleon.Asp.Net/workspace/modules/ and view the various related Atom module files). 

I am also working on, as mentioned above, the integration of the ModuleT microformat into the overall AtomicXML mix such that you can then take this same code base and immediately be enabled to dig into all of the wonder-fullness this exciting new microformat has to offer, building all sorts of mashed up web modules that can be embedded in everything from your AIM Pages page (given ModuleT has been developed by AOL, it makes sense for them to provide direct support for it inside of their personalized web page/community offering), to anything else you might develop and/or any other web company that chooses to provide support for embedded ModuleT components.

So, with all of this, if you are interested in getting started playing with the AtomicXML/Xameleon code base, please check out the following two SVN repositories.

svn co http://extf.googlecode.com/svn/trunk/Xameleon.Asp.Net/

svn co http://extf.googlecode.com/svn/trunk/Dependencies/

You will then want to copy the following assemblies from the Dependencies folder into a newly created “bin” directory inside of the Xameleon.Asp.Net folder,

IKVM.GNU.Classpath.dll
IKVM.Runtime.dll
Saxon.Api.dll
Xameleon.dll
saxon8.dll

Lastly, you will need to go through the registration process for the .omx, .om, and .atom files as mentioned above.  By then mapping IIS to the Xameleon.Asp.Net directory for the site you want to test this with, as well as ensuring the proper permissions for the various groups and users necessary for an ASP.NET application to be enabled to properly access and read from the various folders/files of the applications directory (at the moment, there is no need for write access, though that will be changing in the near-term future) are set, you should then be able to access the default.omx file in the root folder (unless you mapped it to a virtual directory/application to a top-level site) and find yourself staring at the same blank screen you see when you visit,

http://xameleon.org/

Again, please view source to see the actual result of the transformation.

A few more tips:

If you would like for the default.omx file to be served up by default, please add it to the list of documents (”Documents” tab of the web sites property settings form) in the order in which IIS should serve it ahead of any other given file in the same directory specified in this same list.

To learn more about how the various pieces of AtomicXML all fit together,

• Assets, Atom Feeds, and AspectXML - The Triple Threat of Web Development?
• [Part 2] Assets, Atom Feeds, and AspectXML - The Triple Threat of Web Development?
• [Part 3] Assets, Atom Feeds, and AspectXML - The Triple Threat of Web Development?

The first is more of a generalized “Here’s the general idea of using Atom feeds as a way to reference modularized templates and/or data, as well as basic assets (such as CSS, image files, Javascript files, other source code files, etc…), to then output these into any given supported format of choice”

The second gets into the meat of how to go about separating the various pieces of any given web-page/application/etc… into much more specific, and manageable templates and/or data modules, to then weave these together into any given output via any given output definition file.  Plenty of code to dive directly into.

The third goes deeply into the AspectXML weaving engine, which sits at the foundation of everything else.  Again, plenty of code samples to play with.

So with that, while I have several more pieces of content contained inside of the Google Doc’s based document I am currently writing this post in, each of them still require a bit of touch up work before they can be seen as anything other than a collection of random, unfinished ramblings.  Given that the size of this post is now 4 or 5 times longer than I had originally both planned and hoped, I think I am going to hold off and include them in next week’s round-up.

As such, until next time: Enjoy your collective weekends!

Oh, one last thing: A big *PHAT* thank you is due to Dr. Michael Kay, in whom through his hard work and dedication in regards to the development of the XSLT 2.0 spec, the Saxon XSLT/XQuery processing engine, and ongoing support of the XSLT language in general through the XSL-List and Saxon-Help support channels, all of this above is made possible.