Saturday, March 10th, 2007

PUT remains one of the most confusing HTTP verbs because it is so frequently misdescribed, even by people who really do know better. The common description is that PUT is for UPDATE and POST is for creating new resources; and this is wrong, wrong, wrong.

Google and XHTML

Thursday, March 8th, 2007

Apparently Google does not recognize XHTML, at least not when served as application/xhtml+xml. Try this search which should return exactly one hit pointing to an XHTML document. Notice that the file format is “unrecognized” and they offer to let you “View it as HTML”.

XOM XPath Mapping

File Format: Unrecognized – View as HTML
XOM 1.1 supports XPath 1.0 reasonably faithfully. However there are some differences between the XPath data model and the XOM data model you need to be
www.ibiblio.org/xml/XOM/xpath.xhtml – Similar pagesFilter


Academic Prohibitions on Wikipedia are Misguided

Friday, March 2nd, 2007

A couple of months ago the Middlebury College history department banned students from citing Wikipedia in essays and exams. In particular the faculty statement said:

Whereas Wikipedia is extraordinarily convenient and, for some general purposes, extremely useful, it nonetheless suffers inevitably from inaccuracies deriving in large measure from its unique manner of compilation. Students are responsible for the accuracy of information they provide, and they cannot point to Wikipedia or any similar source that may appear in the future to escape the consequences of errors.

However their reasoning is fatally flawed, and speaks toward poor education and worse pedagogy.

Homework for Closures

Thursday, March 1st, 2007

I’ve long been an advocate of outside-in API design. This reflects my interest in user-interface principles in API design. When designing a GUI it is customary to mock it up on paper and then with prototyping tools before implementing the internal code. This helps the interface reflect the user’s goals and expectations rather than the internal data structures of the program. In API design, this means the class becomes more easily usable by decoupled client code.

It occurs to me that the same principles apply in language design. In particular we should try writing some code with proposed new features before we implement the features. This has several advantages:

  • Ensures we get what we need, rather than what the proposal supports
  • Helps us understand exactly what is being proposed
  • Shows the strengths and weaknesses of each proposal
  • Avoids unnecessary features that don’t support a real use case

Consequently herewith are some challenges for the proposers of the various closure proposals. I’ve tried to make them as simple as possible so that the closure issues will be focused on.