On Monday morning at about midnight, I wandered outside my apartment for a quick break before going to bed. My bicycle, with trailer, was parked and locked outside. Nine hours later, after getting updated on my e-mail and showering, I wandered towards my apartment door, and noticed the rear tire of my trailer wasn't visible...
Sure enough, the bike and trailer had been stolen. This prompted some uncivil language at uncivil volumes and lengths... Basically, I was out $700.00 and had no hope of seeing it again.
Until I received a call Thursday afternoon (today) from the Santa Cruz Police Department.
When I purchased the bicycle several months ago, the first thing I did with it was get a bicycle license, registering it with the City of Santa Cruz. That foresight paid off when the City recovered my bicycle in a nearby park on Tuesday - minus trailer, and with some minor damage when the thieves ripped off the trailer, but serviceable. It's in the bike shop now, where I asked the team there to give it "the works", repairing any damage that had been done.
Needless to say, I'm quite happy to have the bicycle back, even damaged. What surprised me was that the thieves made no attempt to remove the license stickers or the serial number on the bike. It was quite obvious they cared only about the trailer, from the damage.
Since I'm moving again in two weeks, I've decided not to bring the bicycle back to my current place. This was the second bicycle trailer I've had stolen from me here. I have no wish to tempt fate or any low-life bastard scum again.
All too often, when you hear about a local city government or its police department, it's usually bad news. This is one case where the City of Santa Cruz, and the Santa Cruz Police Department, did everything right, and did me a fantastic service. My deepest gratitude and thanks go out to them, in particular Officer Inouye and Officer Goodwin, neither of whom I think I've actually met.
This is a two-part article. Please bear with me.
A few weeks ago, I started asking myself this question about Verbosio. If you factor in the time I spent on Abacus (and I do), I have been at this off-and-on project for about four years now, with nothing of real value to show for that time. This is a depressing state of affairs.
I can only answer that question with, "Because there's no tools I know of to do the job better." Specifically, to give me UI's for editing XML documents with language-specific tools (XUL, XBL, RDF, MathML, XHTML, SVG, etc., etc.). It was true four years ago, and it's still true now.
Think about it: how cool would it be to have an application that came, out of the box, with the following options under its File menu:
You fill out a simple form, and there it is. Plus, you have language-specific buttons for editing the document in a given language (XUL), and it's easy to switch to another language (CSS, even though it's not XML).
Or, if you want to add MathML, you drop in a MathML extension, and restart... and MathML is now enabled for editing.
Right now, I still don't know of any tools that can really do this. I've always intended Verbosio as a platform for doing this. After four years, though, I begin to lose faith, encouraged only by the fact that I perceive a real need for it.
Many people blame Internet Explorer for this. Yes, it still has a monopoly stranglehold on browsing the Internet, and yes, IE7 is bringing some improvements, but not enough. But those who blame IE and Microsoft alone are only looking at a small piece of the problem.
Sir Tim Berners-Lee believes we need a Semantic Web, and I'm not entirely sure I disagree with him on that. But even so, this doesn't address other problems with the Web we have now, including the focus of this article.
The World Wide Web Consortium has put out dozens of Recommendations, many of them talking about XML languages such as those mentioned above. XML is a Big Thing, and not going anywhere. What we can do with XML, and specifically certain XML languages, is truly astonishing.
Creating XML documents with those languages in the first place, though...
Fundamentally, that's what Verbosio is about. Sure, tools for generating HTML are everywhere, and it's relatively easy to convert HTML to XHTML most of the time. But what about MathML, or SVG at the same time? RDF? How can you create the content flexibly through a GUI?
(Note: Please spare me the snide remarks suggesting a text editor. Text editors are just about the most inefficient way to create XML markup that there is.)
The simple fact is, tools to create such rich XML markup are not widely known and available. I truly and honestly believe this holds the WWW in the year 2000 more than Microsoft and Internet Explorer do.
While browsing the WWW has improved dramatically (Firefox, Opera, Safari, Camino, etc.), and e-mail has had similar improvements (Thunderbird, and forgive me for forgetting the other major e-mail clients out there with frequent releases), that simply means the ability to read the WWW has improved. No corresponding improvements to writing the WWW have been nearly as widespread.
The old Composer application, as it belonged to Netscape (when Netscape was a real company a decade ago), and later Mozilla, was a critical success at providing HTML editing capability. I dream of a similarly successful rich XML editor at my fingertips. ETNA may be that solution. Verbosio may be that solution. Or it may be something else. Amaya isn't quite that solution, but it's good for its purposes. A tool allowing me to edit XHTML, MathML, SVG, RDF, etc. simultaneously through a GUI that makes me think I'm editing XHTML, MathML, SVG, RDF, etc. instead of making me think I'm editing vanilla XML, is a tool desperately needed.
I've said before I work for ManyOne Networks, and two of our sponsored projects are the Digital Universe and the Encyclopedia of Earth. When you get down to it, though, these sites are about hosting and linking to accurate content. The better tools there are to edit said content, the better the experiences of our customers will be. In this respect, it's fortunate for me to work at ManyOne Networks. They want to offer content and content services, and I want to offer content editing services.
The World Wide Web is a fantastic creation; without it, you'd likely not be reading these words. But even now, the blogging software I'm using to write this article can't let me easily create artwork. We can see the artwork just fine. But no one can appreciate that which has not been drawn.
Until that day comes, I fear even blog articles will be restricted mainly to the realm of hypertext and digital camera pictures. We can read so much more than we can write that we don't even know what we can read or write. It really is time to put pen to paper, instead of just reading everyone else's papers which are no more capable than our own.
For years, I've wanted to think about using content MathML and SVG to plot a y = f(x) function on a pair of axes. The SVG part of this is not too hard (alas, I lost every copy of my SVG grapher years ago, and will have to rewrite it), but MathML is a whole different ball of wax.
So, with a little bit of thought (and a need to do something different than I've done recently), I came up with this: contentMathEval.js. This script takes a MathML content node and attempts to evaluate its value with a given set of variable inputs. It also offers a way to get a composite JavaScript function, equivalent to the MathML content node and its descendants.
Pretty cool, huh? It doesn't cover all of MathML, not by a long shot. It's a starting point, for the most basic of functions in MathML (specifically, those covered by ECMAScript's Math object, and basic arithmetic).
I have a demo of contentMathEval.js here, and contentMathEval.js includes some internal documentation on how to use it. Most of it hasn't been tested yet.
I don't plan on making immediate improvements to this script, but I will take code contributions if anyone's interested. Something more advanced (with support for my BigDecimal library, and probably derivatives and integrals) I will probably tackle at a future date.
I must have been asleep at the wheel, again. Last Friday, the XBL 2.0 specification became a Last Call Working Draft.
I'm personally pleased to see the design behind the new <implementation/> element. It would mesh very nicely with my precondition/postcondition article of a few days ago. It would also be nice to have support for <xbl:script/>. I will probably spend an hour or so reading over the specification in closer detail this week, in particular trying to understand this public/private object stuff.
Slashdot pointed me to this ZDNet blog entry talking about Rich Internet Applications. In there is a paragraph on XUL. I quote:
While I'm sure I might get flamed a bit by the XUL community for saying so, XUL is currently a good working model for how not to build a broadly accepted RIA platform, despite some technical greatness.
Believe it or not, I actually agree. It is Mozilla-only, and Mozilla-based products don't make up a massive part of the market share. (Fifteen percent is respectable, just not massive.) XUL would be much better if it was a standard implemented for multiple platforms - but each vendor makes their own decisions on what to do. This isn't necessarily a bad thing, but it's something to deal with.
If the W3C were to provide such a unified language (and with XAML coming up, it may be forced to), then all would be well. But I don't expect W3C to do so. Maybe WHATWG... maybe.
With all the talk about IE 7 coming out with a bunch of improvements, I have been wondering for a long, long time what improvements to the Document Object Model, if any, IE 7 is bringing out. Here is Microsoft's page on IE 7 DOM changes.
I'm actually very disappointed in what I see there. There's no documented support for:
I'm sure there are many other things missing, but these three are so useful for Mozilla-oriented scripted content that not having it for IE really hurts. The above specifications became W3C Recommendations almost six years ago...
IE 7 is in RC 1 phase now, so I wouldn't count on having these for IE 7 final. I hope someone on Microsoft's IE team reads this and would be willing to start work on these features for IE 7.1 or IE 8. The World Wide Web needs stuff like this!
They are bringing improvements to XMLHttpRequest, which many web developers will appreciate.
For everyone else, please, no flames about IE. They know as well as we do just how hard it is to release a browser for the whole world. Some things were not going to make it.
Two years ago, I wrote an article describing a design-by-contract library for JavaScript. This morning, I realized I wasn't using it anywhere in my new projects. This really bothers me - a tool that not even the inventor will use?
I did a little thinking, and realized one of the big problems was in object construction, where I literally couldn't use it. The old DBC-JS file had the approach of requiring users to call a separate function to execute the contract: var root_3 = applyContract(getSquareRoot, this, 3); instead of this.getSquareRoot(3).
Ease of use beats functionality hands-down. Firefox taught us that for user interfaces, and this demonstrates the same for actual code. So obviously I had a design flaw in my design code.
Enter one of the little used features of JavaScript: you can define functions inside functions. The inner functions are treated as local variables. Moreover, any local variables in the outer functions are available to the inner functions.
To spare feedreaders from unwanted technobabble, I'll continue the rest of this on a secondary page.
Observe the following function:
Note the getContractFunction actually returns a function, not an object or an ordinary value. If I have code like this:
Then the only call a user of sqrtObject has to make is sqrtObject.sqrt(9). No applyContract() mess!
Suppose, though, you want your contract function to be a constructor. For that, the inner function of getContractFunction() is even simpler:
Contracts are thus simplified enormously. Here's some sample code to demonstrate this new design-by-contract library:
Here's the updated ecmaDebug.js file, with the new contract code. It also includes my custom NS_ASSERTION firing function for debugging purposes when Venkman just isn't enough. Other features: toString and toSource have been redirected to the contract's body (so you can see what the function's really supposed to do). Also there is a toContractSource() and toContractString() which deliver the whole contract object in source and string form, respectively.
Feedback welcome!