Copia

I'll be giving a presentation at the upcoming XML 2006 Conference in Boston on Tuesday December 5th at 1:30pm: The Essence of Declarative, XML-based Web Applications: XForms and XSLT.

I've been doing some hardcore XSLT/XForms development over the last 2 years or so and have come to really admire the versatility of using XSLT to generate XForms user interfaces. Using XSLT to generate XHTML from compact XML documents is a well known design pattern for seperating content from presentation. Using XSLT to generate XHTML+XForms takes this to the nth degree by seperating content from both presentation and behavior (The Model View Controller design pattern).

The icing on the cake is the XPath processing capabilities native to both XSLT and XForms. It makes for easily-managed and relatively compact applications with very little redundancy.

The presentation doesn't cover this, but the XForm framework also includes transport-level components / mechanisms that are equally revolutionary in how they tie web clients into the overall web architecture context very comprehensively (Rich Web Application Backplane has good coverage of patterns to this effect). I've always thought of XForms as a complete infrastructure for web application development and AJAX as more of an interim, scripting gimick that enables capabilities that are a small portion of what XForms has to offer.

[Uche Ogbuji]

I'm wrapping up applyxslt, a WSGI middleware module to serve separate XML and XSLT to browser that can handle it (using the stylesheet PI. For browsers that can't it would intercept the response and perform the XSLT transform for the browser, sending on the result. BTW, for more on WSGI Middleware, see “Mix and match Web components with Python WSGI”.

My biggest uncertainty is the best way to determine whether a browser can handle XML+XSLT. I doubt anything in the Accept header would help, so I'm left having to list all User-Agent strings for browsers that I know can handle this (basically Firefox, Opera, and recent Mozilla, Safari and MSIE).

So far I'm deriving my User-Agent list from several sources, including

• Wikipedia (the daddy of all User-Agent lists I've seen)
• "Masquerading Your Browser", by Eric Giguere (the "Common User-Agent Values" section) and
• "Understanding user-agent strings"

Really the Wikipedia list is all I needed, but I found and worked with the other ones first.

So based on that here is the list of User-Agent string patterns I am treating as evidence the browser does understand XML+XSLT (Python/Perl regex):

.*MSIE 5.5.*
.*MSIE 6.0.*
.*MSIE 7.0.*
.*Gecko/2005.*
.*Gecko/2006.*
.*Opera/9.*
.*AppleWebKit/31.*
.*AppleWebKit/4.*

Note: this hoovers up a few browser versions I'm not entirely sure of: Minimo, AOL Explorer and OmniWeb. I'm fine with some such uncertainty, but if anyone has any suggestions for further refinement of this list, let me know. I'd like to keep it updated.

[Uche Ogbuji]

GRDDL. What is it? Why the long name? It does something very specific that requires a long name to describe it. Etymology of biological names includes examples of the same phenomenon in a different discipline. I starting writing on this weblog mainly as a way to regularly excercise my literary expression, so (to that end) I'm going to try to explain GRDDL in as few words as I can while simultaneously embelishing.

It is a language (or dialect) translator. It Gleans (gathers or harvests) Resource Descriptions. Resource Descriptions can be thought to refer to the use of constructs in Knowledge Representation. These constructs are often used to make assertions about things in sentence form - from which additional knowledge can be infered. However, it is also the 'Resource Description' in RDF (no coincidence there). RDF is the target dialect. GRDDL acts as an intelligent agent (more on this later) that performs translations from specific (XML) vocabularies, or Dialects of Languages to abstract RDF syntax.

Various languages can be used but there is a natural emphasis on a language (XSLT) with a native ability to process XML.

GRDDL is an XML & RDF formalism in what I think is a hidden pearl of web architecture: a well-engineered environment for distributed processing by intelligent agents. It's primarily the well-engineered nature of web architecture that lends the neccessary autonomy that intelligent agents require. Though hidden, there is much relevance with contemporaries, predecessors, and distant cousins:

• Narval
• RDF Scutters
• Redfoot
• Document Definitions

It earns its keep mostly with small, well-designed XML formats. As a host language for XSLT it sets out to be (perhaps) a bridge across the great blue and red divide of XML & RDF. To quote a common parlance: watch this space.

Chimezie Ogbuji]

I think my response to the recent news that Guido had "pronounced" Django as the Python Web framework was "so wot's 'e think 'e's doing, anyway?"

First of all, I don't think it's a big deal. Every few months something happens to get the Python world all abuzz about the number of Python Web frameworks. It might be the announcement of a new one (Django, TurboGears, web.py, Clever Harold, etc.). It may be some bit of Ruby on Rails news, which for some reason seems to strike fear into the depths of Pythoneers' consciousness. (I think O'Reilly amuses themselves by publishing book sales figures just to see how high they can get some in the Python community to jump). Whatever the stimulus, people blog back and forth about it, a handful of folks switch frameworks, just to be safe, but in the end it all dies down with the status quo still pretty much as it is. When Python Web frameworks die (which seems to be a rare event), they die with a whimper, and not a bang.

Some might think that a BDFL "pronouncement" is no ordinary stimulus, but I'd bet good money that this case is indeed quite ordinary. You see, that's where we have these lovely things called boundaries and it seems one has unmistakably been exceeded in this case. When the BDFL pronounces on a matter, it has always been with the intention, and effect, of settling a troubling argument once and for all. That's not possible in this case. It's not as with Python decorators where Guido's decision to include them, and his choice of syntax, became part of the language proper, and the only thing you could do if you disagreed was take the enormous step of forking the language. In this case, if you disagree with Guido, what do you do? You ignore him and keep using (or developing) your favorite framework. Nothing in the evolution of Python impedes you the slightest bit. In the end, I think this is what each individual developer will end up doing. A few will indeed give Django a new look, and some will convert, but in the main, all will be back to normal in a few weeks.

For my part every sniff I've had of Django makes me think it's way too large and monolithic for my taste. In other words, it's far too much like Zope. (Speaking of Zope, if it were ever appropriate to declare one Python framework to rule them all, Zope is the one with the popularity and maturity for such a role—which is why I'm glad such a declaration is not appropriate). I understand they're getting rid of a lot of the magic, which is another thing that gave me flashbacks of Zope, but I doubt that would be nearly enough for me. For now, I'll continue to work with my favorite three frameworks: CherryPy, RhubarbTart and Pylons, although I do carry some hope that the latter two will merge, and leave me with just two favorites. I'll also focus as much Web development work as I can in creating WSGI middleware, which provides the greatest flexibility.

See also:

• Ben Bangert points out Guido's earlier resolve not to endorse any one framework (he also gets lotta luv from other Pylons users)
• Jeremy Hylton, whose stance seems similar to mine
• Christopher Lenz, who echoes my impressions of Django

[Uche Ogbuji]

Last week I told a story of how GoDaddy's customer service told me I'd forfeited a certificate I'd purchased when I didn't use it in 60 days. On Friday I got a voice mail from someone in "the office of the president of GoDaddy.com". She told me they had restored the certificate to my account. Surely enough, the credit is there.

Things that make you go "hmmmmm". I'm not sure I like the possibility that I get by Weblogging a complaint what I could not get by making the same complaint to customer service. Of course, that's just one possibility. As I hinted in my earlier entry, even at the time of the annoying incident I suspected I was dealing more with a clueless customer service rep (as well as his clueless supervisor) than a true corporate policy of seizing my certificate. I might have called the number right back and reached a rep who sorted out the problem right away. Or perhaps if I'd sent my complaint to the company, rather than posting it, they'd have been as attentive. This sort of thing happens all the time.

My friend David Courtney who related the following story:

I read about your GoDaddy experience. I have to say, I'm rather surprised you were treated this way. I shall have to re-evaluate my opinion of GoDaddy. I registered the ultradesic.com domain with them last year and bought a Turbo SSL certificate. Once my data center issued myCertificate Signing Request, I went to the GoDaddy website to get the SSL certificate. I took that SSL certificate back to my data center only to find out they had used an invalid method of generating the original CSR. They gave me a new CSR. I went back to GoDaddy only to find out that once the key was issued, you couldn't get a new key. I was extremely aggravated at my data center for messing up the process. But in this case, the GoDaddy person I communicated with via [username omitted]@godaddy.com was extremely helpful. He immediately issued me a credit for my certificate so I was able to generate a new certificate from the new CSR.

I had another somewhat similar problem this year. I was sick of dealing with my data center's total disregard for security. (i.e. no ssh access to my domain. I had to use plain text FTP to get anything done.) So I moved to a new data center. Well, because I moved my domain to a new location, I had to generate my certificate all over again. When I went to my account at godaddy.com, I again ran into the problem of "The key has been issued, you can't re-key it." But I again e-mailed [username omitted]@godaddy.com and the problem was resolved very quickly. He credited me a certificate for both my domains, no questions asked.

This is in line with everything I'd heard about the company before last week, so I'll assume I just caught a it of bad luck in the customer service lottery and accept their olive branch in good grace, putting last week's incident aside for now.

[Uche Ogbuji]

I wrote an article a while back, "Thinking XML: Patent filings meet XML" in which I covered, among other things, the various patent agancies' efforts to support electronic filing. Many of these efforts are XML-based. Except now perhaps the USPTO's (EFS-Web) isn't. There were a lot of gnarly aspects of the EFS-Web process, and I had heard from some users who ended up abandoning the system. It looks as if the USPTO is trying to address these problems by chucking the whole approach and just having people upload PDFs (via XML.org Daily Newslink--yeah. I'm way behind). I wonder whether they also considered supporting ODF, at least as an alternative to PDF. It seems to me that what they needed was broader, not narrower format and tool support.

[Uche Ogbuji]

In March we purchased a package from GoDaddy. The purchase package looked in part like the following:

QTY ITEM                                            PRICE
1   .COM Domain Name Transfer - 1 Year              $2.24
    FOURTHOUGHT.COM
24  Premium Hosting w/ PHP / PERL- v2               $287.04
1   Turbo SSL (2 Years)                             $0.00

Getting the included certificate was a large part of the incentive for choosing this package and vendor (GoDaddy), but we didn't get around to using it right away. Today, after a bunch of much-needed server maintenance we were ready to set up and use the cert. I went to our account info to find that GoDaddy claimed we had no credit for an SSL certificate. Figuring it was a simple error I cheerfully called customer support.

I was surprised to be told me that since we had not used the certificate for 60 days, we could not have it. I asked why and thee gentleman on the phone went on about how we didn't pay for the certificate, anyway. I scoured our purchase receipt and did a few likely text searches on the huge GoDaddy customer agreements and I found no notification of the 60 day forfeiture. I pointed this out to him at which point he became defensive, saying it had to be in the documentation somewhere and at any rate there was nothing he could do to help me. He kept telling me that we had not paid for the certificate anyway. I told him that even though the invoice shows a $0 line-item for it, it was part of a package deal, and so in paying for the whole package we had paid for the certificate. He kept repeating, as if a mantra to make me go away, that we hadn't paid for the certificate. I explained that I could understand if we were now given a certificate that expired March 2008, and thus forfeited the unused portion of the two-year duration, but he insisted there was nothing that could be done. I asked to speak to someone who might be a bit better authorized to deal with the situation, and he was very reluctant until he finally passed me to his "floor supervisor".

This gentleman told me that since I had not used it for 60 days, the certificate counted as an "unused product". He said that he couldn't restore it to our account because it was "free" and so there was no money to refund and re-purchase. I asked him whether he was willing to restore the cert form a customer service point of view, but he was facing a system limitation because of the $0 line-item. In short I was kinda giving him a way out. I would have been at least a little mollified if they were technically hamstrung rather than obstinate about playing "GOTCHA! 60-day forfeiture", along the lines of a particularly rough game of Calvinball. Strangely he refused to really admit it as such. He kept insisting that the problem was that we had "never paid for a certificate". I imagine they're trained to never admit any sort of fault. I only have so much time in the day so I left off the matter at that point.

I guess my main point is to be careful when dealing with GoDaddy.com about undisclosed limitations on their offerings. I think the 60 day "unused product" limitation is a poor policy in the first place, but I'd understand better if it had at least been disclosed. As far as I can tell, it had not been.

I'll go ahead and purchase a certificate form another vendor. I shall not do any business in future with GoDaddy.com. I'm sure other vendors will be more costly, but honestly, a few extra bucks per domain-year is well worth the principle.

I hope this note saves anyone else such a surprise.

[Uche Ogbuji]

“XML in Firefox 1.5, Part 3: JavaScript meets XML in Firefox”

Subtitle: Learn how to manipulate XML in the Firefox browser using JavaScript features
Synopsis: In this third article of the XML in Firefox 1.5 series, you learn to manipulate XML with the JavaScript implementation in Mozilla Firefox. In the first two articles, XML in Firefox 1.5, Part 1: Overview of XML features and XML in Firefox 1.5, Part 2: Basic XML processing, you learned about the different XML-related facilities in Mozilla Firefox, and the basics of XML parsing, Cascading Style Sheets (CSS), and XSLT stylesheet invocation.

Continuing with the series this article provides examples for loading an XML file into Firefox using script, for applying XSLT to XML, and for loading XML with references to scripts. In particular the latter trick is used to display XML files with rendered hyperlinks, which is unfortunately still a bitt of a tricky corner of the XML/Web story. I elaborate more on this trick in my tutorial “Use Cascading Stylesheets to display XML, Part 2”.

See also:

• Copia announcement of the first article
• Copia announcement of the second article
• More on the XML+CSS tutorial series

[Uche Ogbuji]

I'd long ago put up a very thick lens for looking at any news from the SOA space. With analysts and hungry vendors flinging the buzzword around in a mindless frenzy it came to the point where one out of twenty bits of information using the term were pure drivel. I do believe there is some substance to SOA, but it's definitely veiled in a thick cloud of the vapors. This week Service Modeling Language caught my eye through said thick lens, and I think it may be one of the more interesting SOA initiatives to emerge.

One problem is that the SML blurbs and the SML spec seem to have little substantive connection. It's touted as follows:

The Service Modeling Language (SML) provides a rich set of constructs for creating models of complex IT services and systems. These models typically include information about configuration, deployment, monitoring, policy, health, capacity planning, target operating range, service level agreements, and so on.

The second sentence reads at first glance as if it's some form of ontology of systems management, basically an actual model, rather than a modeling language. No big deal. I see modeling languages and actual models conflated all the time. Then I catch the "typically", and read the spec, and it becomes evident that SML has much more to it than "models of complex IT services and systems". It's really a general-purpose modeling language. It builds on a subset of WXS and a subset of ISO Schematron, adding a handful of useful data modeling constructs such as sml:unique and sml:acyclic (the latter is subtle, but experienced architects know how important identifying cyclic dependencies is to risk assessment).

I'm still not sure I see the entire "story" as it pertains to services/SOA and automation. I guess if I use my imagination I could maybe divine that an architect publishes a model of the IT needs for a service, and some management tool such as Tivoli or Unicenter generates reports on a system to flag issues or to assess compatibility with the service infrastructure need? (I'm not sure whether this would be a task undertaken during proposal assessment, systems development, maintenance, all of the above?). I imagine all the talk of automation in SML involves how such reports would help reduce manual assessment in architecture and integration? But that can't be! Surely SML folks have learned the lessons of UDDI. Some assessment tasks simply cannot be automated.

SML shows the fingerprints of some very sharp folks, so I assume I'm missing soemthing. I think that much more useful than the buzzword-laden blurbs for SML would be an document articulating some nice, simple use cases. Also, I think the SML spec should be split up. At present a lot of its bulk is taken up defining WXS and ISO Schematron subsets. It seems a useful profile to have, but it should be separated from the actual specification of SML modeling primitives.

[Uche Ogbuji]

"Get free stuff for Web design"

Subtitle: Spice up your Web site with a variety of free resources from fellow designers
Synopsis: Web developers can find many free resources, although some are freer than others. If you design a Web site or Web application, whether static or with all the dynamic Ajax goodness you can conjure up, you might find resources to lighten your load and spice up your content. From free icons to Web layouts and templates to on-line Web page tools, this article demonstrates that a Web architect can also get help these days at little or no cost.

This was a particularly fun article to write. I'm no Web designer (as you can tell by looking at any of my Web sites), but as an architect specializing in Web-fronted systems I often have to throw a Web template together, and I've slowly put together a set of handy resources for free Web raw materials. I discuss most of those in this article. On Copia Chimezie recently mentioned OpenClipart.org, which I've been using for a while, and is mentioned in the article. I was surprised it was news to as savvy a reader as Sam Ruby. That makes me think many other references in the article will be useful.

[Uche Ogbuji]