Archives for 2009

A Standard I Would Use: Auto Unsubscribe

2009/08/19 By Rob 8 Comments

I don’t get a lot of spam, at least not in the traditional sense of “unsolicited commercial email”. But I do get a lot of solicitations from online retailers with whom I have done business. As we all know, even a single order can trigger weekly emails. Multiply that by all places I do business with, and I end up with a lot of unwanted emails.

Certainly, the vast majority of these companies offer an unsubscribe option, with instructions clearly marked at the bottom of the email. These instructions tend to have a URL which I click and one of three things happen:

Link automatically unsubscribes me
Link takes me to a web page that asks for confirmation and maybe a little survey, or a list of mailings which I can opt-in or out of.
Link takes me to a login page, where I need to remember my login id, navigate to a profile and perform several other steps before I can unsubscribe. I have some mailing lists that I have never been able to unsubscribe to at all. I end up defining inbox rules to delete the mailings altogether.

The idea for a standard is this: Can we encode these unsubscribe mechanisms, or at least the first two mechanisms, in a standard way in the mail message itself, so that an email client can allow the user to simply push a button and activate the unsubscribe procedure? If done right, I could even be in my inbox view and select several emails and unsubscribe to those lists all at once. Ideally no further user interaction would be required. And certainly I want to avoid the requirement to hunt through an email for the unsubscribe link.

Since emails can come in a variety of formats, from text, to HTML to RTF, it might make sense to handle this in the mail headers rather than the email body itself.

Of course, we want this to be simple and declarative and not require general-purpose scripting support, for simplicity and security reasons.

I think this would be a relatively simple standard to create. We just need some conventions for an email to declare a RESTful API for unsubscribing to a list.

Of course, maybe there is something like this already out there?

How Not to Read a Patent

2009/08/13 By Rob 11 Comments

There is perhaps no occasion where one can observe such profound ignorance, coupled with reckless profligacy, as when a software patent is discussed on the web. Note the recurring pattern, which is repeated every two weeks or so. A patent issues, or a patent application is published or patent infringement suit is brought, and within minutes the web is full of instant pundits, telling us what the patent covers, how it should not have been granted, how it is entirely obvious, or how it applies to everything in the world, and how it presages a self-induced mutually assured destruction that now leads us on to the plains of Armageddon. If I had a nickel for every time this happens…

By way of disclaimer, I am not a lawyer, but I am blessed that my self-avowed ignorance in this area is coupled with a certain knowledge of the limits of my understanding, a handicap seemingly not shared by many other commentators. I know what I do not know, and know when to seek an expert.

In the past few days we have had a bumper crop of pontification on the significance of two XML-related patents, one newly issued to Microsoft (7,571,169), and another older one (5,787,449) owned by i4i, whose infringement has resulted in a large judgment and injunction against Microsoft. I’ve found the web coverage of both patents to be an unmitigated muddle.

I’m not going to comment on the merits of either one of these patents, but I’d like to make a few basic observations that may be of some assistance to those who comment on future patent issues.

A patent has a description known as the “specification”. And it has a list of numbered “claims”. Although the specification can define terms that are then referred to in the claims, it is the granted claims that define the scope of the patent, not the specification.
If all you do is read the abstract and the first few paragraphs of a patent, then you may know the general topic of the patent, but you do not really know its scope. If you then go off and cry, “Oi vey, this patent covers XHTML, SVG, RDF, Pringles and Obama Healthcare Plan” then you do your readers a disservice. You must parse the very specific and often obtuse language of the claims in order to understand exactly what a patent covers. There is no short cut. This is not like a book where you can understand the plot by reading the back cover. But over and over again, I see people who just read the abstract, maybe glanced at a diagram, and then feel equipped to hold forth at length on the substance of the patent.
When you try to understand patent claims, you will encounter a dense form of legal English. Claims are not written for a layperson and do not presume that you will understand it easily. The drafting of patent claims is a black art, like writing device drivers, and if you are not versed in its intricacies, then your statements on any given patent are apt to be wide of the mark. Claims are full of magic words. Know what you do not know. If you do not recognize at sight and know the interpretation requirements of a means-plus-function claim (which is key in the ‘449 patent), or you are not crystal clear on the distinction between the verbs “consist” and “comprise”, then you probably should not be the first (or loudest) person to speak on what a patent claims.
If you are reading an application, know that during the “prosecution” of that patent, when it is reviewed by the USPTO, some of the claims of the patent may be thrown out, for any of several reasons, including prior art identified by the examiners. However, the specification of the patent is unlikely to change much. So an issued patent often has a very broadly-written specification, that covers the entirety of the originally claimed invention, though the the issued patent might have only a subset of the original claims allowed. So if you are have an issued patent and you look at only the specification, you can easily be fooled into thinking it covers far more than it does. For example, the ‘169 patent from Microsoft had half the original claims thrown out in the prosecution. If you don’t know that and are reading only the specification, not the granted claims, then you will incorrectly think the patent is far broader than it actually is.
Know what a priority date is, and how that is affected by a continuation. I’ve read all sorts of nonsense based on not appreciating that. Take a look at the ‘169 patent, for example. It says it was filed in 2004. But if you look closely you see it was a continuation of a 2002 application. You can moan and groan all you want about prior art, but if you don’t get your dates right you’re off to a bad start in your analysis.
In an infringement suit, like with the ‘449 patent, be sure to look at the actual court record. Typically there is a Markman (claim construction) hearing, where the court will determine the meaning of terms used in the patent claims. If you have not read the court’s claims construction opinion in the i4i versus Microsoft case, then your commentary is uninformed by probably the most important document in this case (well, next to the patent itself).

Well, that’s enough for tonight. Repent. Sleep on it. And realize that making sense of a complex patent takes time, if you’re going to do it right. Ergo, the first impressions you read from the instant pundits on the web will tend to be shallow, imperfectly informed and often wrong. Heck, even everything I said in this post may be wrong.

ODFDOM 0.7 Released

2009/07/21 By Rob 2 Comments

I’m pleased to report that the 0.7 release of the ODF Toolkit Union’s ODFDOM library has just been released. This is an open source (Apache 2.0 license) Java toolkit for programmatically reading, writing and manipulating ODF documents. The code is 100% Java and does not require that you have OpenOffice or any other ODF editor installed. It operates directly on the document itself.

You can download the JAR and JavaDoc from the distribution here. You will want to go through J. David Eisenberg’s tutorials on ODFDOM as well.

If you sign up for a Toolkit Union account, you’ll be able to participate in the user’s mailing list (users@odfdom.odftoolkit.org) where we welcome your ideas, bug reports and patches. Or better yet, move over to the dev list (where the real fun is) and contribute actively!

The ODF Toolkit also has an active “Conformance Tools” project, including the ODF Validator, and our most-recent project, AODL, which is a .NET/C# module.

At the Toolkit Union we’re able to host more such ODF-related toolkit projects, in other programming languages. I don’t see any good reason to have two Java API’s for ODF, but I’d love to see broader coverage, especially in some of the more-widely used scripting languages like Python or Perl. I have even seen some interest in a PHP/ODF module. I think there is some advantage to getting a “critical mass” of programmers interested in working with ODF together in one place to bounce ideas off of each other. So if you are interested in joining this effort, sign up at the Toolkit Union’s web site, or send me a note if you want to talk first.

[22 July 2009 — more on ODFDOM 0.7 in this post by project lead Svante Schubert]

July 20, 1969

2009/07/19 By Rob 3 Comments

Paul Calle (1928-) drew science fiction illustrations, including for now-legendary magazines like Galaxy Science Fiction and Amazing Stories. Then a funny thing happened. The science fiction became real. Sputnik launched in October, 1957. NASA was created in 1958. Glenn orbited the earth in 1962. The space race was on.

In the Fall of 1962 NASA chief James Webb created the NASA Art Program. Under the direction of James D. Dean, artists were invited to Cape Canaveral, to observe and interact with the astronauts and staff and to document history in the making.

The invitation letter stated:

When a major launch takes place, more than two hundred cameras record every split second of the activity. Every nut, bolt and miniaturized electronic device is photographed from every angle…but as Daumier pointed out a century ago, “The camera sees everything but understands nothing.” It is the emotional impact, interpretation and hidden significance of the events that lie within the artist’s vision.

Paul Calle was one of the artists engaged, during the Mercury, Gemini and Apollo missions. Calle’s illustration of the Apollo 11 moon landing is one of the iconic images of landing, as reproduced in the 1969 air mail stamp, Scott # C76, in 6-color Giori process:

We’ll be remembering a lot tomorrow — the astronauts, the engineers, the journalists — that all contributed to what was a defining moment of the modern era. Let’s also remember the artists and the part they played.

(And why don’t we have any good moon landing songs from the time?)

How I think Wikipedia works

2009/06/30 By Rob 13 Comments

I have a mental model of how Wikipedia works and behaves. This may not reflect reality, but it is how I, as an end-user, expect Wikipedia to behave. I think these are reasonable expectations regarding things like standards of proof and balance and that if the real Wikipedia differs substantially from these expectations, then we have a problem.

Please let me know if my mental model differs from reality.

First, I assume that we deal with facts, not opinions. So an editor cannot state a personal opinion such as, “Citizen Kane is the greatest movie ever made”, since there is no objective, recognized scale for cinematic greatness.

However, saying, “Citizen Kane topped the list of ‘Greatest Films’ according to a 2002 poll of directors and film critics by Sight & Sound magazine” would be fine. It is a factual statement, albeit a statement about an opinion, but the factual portion of it is verifiable. It is a fact about an opinion and that is OK.

But if I made the statement, “Citizen Kane is the greatest movie ever made” and cited the Sight & Sound article, this would not be proper, since that article does not establish the fact of the greatest movie, but only the fact of a poll that collected opinions on the greatest movie. A fact about the existence of an opinion (or even a polled opinion) does not assert the truth of the opinion.

Similarly, a statement, “Gone with the Wind has been criticized for its long running time” would not be properly cited by merely referencing a source that states its length as 238 minutes. That citation would merely be evidence of its length, not that its length was inordinate. You need a citation for the length being criticized.

Similarly, if another recognized expert stated, “Gone with the Wind was too short and failed to cover the entire Mitchell novel”, then I would expect both opinions to be mentioned, not merely selecting an arbitrary opinion.

I also expect that cited sources have recognized (not merely self-declared) expertise in the area. So, I would find it idiosyncratic if an article on cinema said, “Citizen Kane is the greatest film ever made, according to a fan blog post by Joe Blow, a ophthalmologist in Podunk, Michigan”, since he would be a source cited outside any area of recognized expertise.

I also, as a user, expect Wikipedia to give a balanced view of issues. This does not mean equal time to all fringe opinions. Although I expect there to be multiple views presented on the propriety of the Iraq War, I would not expect that someone who believes that Abraham Lincoln was an alien from the planet Quthbral to have a section in the Lincoln article, even if he could cite a blog post or a photocopied article, or self-published book on the subject. Ditto for Flat Earth Society members, holocaust deniers and those who think the Apollo moon landing was filmed on a Hollywood sound stage.

On the other hand, I don’t expect that every fact requires a citation. For example as a user, I don’t expect to see citations whenever someone says “Mercury is the closest planet to the Sun”. Similarly, I would find it odd if someone removed that assertion for lack of a citation.

However, I would be suspicious if someone writes something in the form, “Mercury is the hottest planet because it is closest to the Sun”. Although the it is well known that Mercury is the closest planet, it does not follow that it is the hottest. In fact, Venus is the hottest planet. It is a subtle form of editorializing, where an editor can inadvertently introduce personal assumptions into an article. I’m assuming Wikipedia editors are on the watch for this kind of thing.

On the other hand, some things clearly logically follow from known facts. If we know that John Brown was buried on January 23rd, 1582, then we should, absent contrary evidence, safely be able to state that his date of death was on or before January 23rd, 1582. I would not expect someone to revert such a statement as being unfounded, speculation, original research, etc. It logically follows based on our knowledge of how the world works.

Does anyone know whether the above statements have any basis in the aspirations or actual practice of Wikipedia editors and admins? Sadly, my recent reading of some articles suggests that these reasonable expectations are routinely flouted and bear little resemblance to reality.