mult.ifario.us

Yesterday, I put together a RNC schema for the legacy version of BPEL, a.k.a. BPEL4WS 1.1. After writing a few processes, I've made some corrections, and I've also put together a RNC schema that matches the current (September 2, 2004) commitee draft XML schema.

Emacs with nxml-mode has become my XML editor of choice, thanks to real-time validation and context-sensitive editing features. The price of the elegance and utility is that nxml-mode requires a Relax NG compact syntax ("RNC") schema, and most of the documents that I work with are defined by XML Schema.

So, with the intention of using Emacs as an editor for WS-BPEL, I put together a RNC schema for the legacy version of WS- BPEL, a.k.a., BPEL4WS 1.1. You can download the schema from here. The schema comes without the 14.3 "enhancements" to assignment enabled, but there is a comment that explains how to make the one-line change needed.

This was my first outing with the RNC syntax, and after a quick skim over the tutorial, the terseness of the syntax is agreeable. For writing RNC, David Rosenborg's rnc-mode was helpful, and nxml-mode will "validate" RNC documents when it loads them. (To specify a schema for a document, use C-cC-s.)

I now have the following in my .emacs:

(setq auto-mode-alist
      (cons '("\.\(xml\|xsl\|rng\|xhtml\|bpel\)\'" . nxml-mode)
	    auto-mode-alist))

and it works like a charm. As a bonus, some of the little differences between Relax NG and XML Schema allow the RNC version performs some validation that the XML Schema is not able to, e.g., knowing the various legal attribute combinations versus all possible attribute combinations on a <bpel:from>.

My spam corpus has just crossed 70,000 messages, so it's time for a quick retrospective on the last 10,000 messages. It looks like spam is picking up speed, with ~240/day (peaks over 300/day) for the last 10,000 versus ~215/day for the 10,000 before last and ~205/day for the 10,000 before that. With this last set of messages, the distribution of spam probabilities (as rated by bogofilter) is starting to flatten out a bit, so I'll probably have to tune the paramters or add an additional type of filter.

Although I don't get much chance to read, I've started a new non-fiction book, Bringing Down the House, about a group of MIT grad students who used refined card-counting techniques to beat the odds in blackjack.

If memory serves, the classic card counting techniques provide a about a 1% advantage over the house. That is, there is an asymptotic 1% advantage assuming an infinite bank; a simulation shows that actually realizing that advantage requires a substantial bank and patience -- something like 100 times the bet as a bank to reduce the chance of going bankrupt to 1%. A fancier heuristic can make a big difference, however. When I was a graduate student and had an opportunity to get over to Reno from Berkeley, I experimented with a four-slot card sorting technique that used both the weighted sum of the different category counts and the shape of the histogram ("buck-toothed" or "gap-toothed" shapes added additional information) to make decisions. I never had the time to run a real simulation, but the heuristic worked relatively well in practice even if I occasionally made stupid moves (intentionally, of course) to make it look like I was just being lucky. At any rate, coming up with a heuristic that provides useful information in practice (multi-deck shoe, different seating positions at the table, etc.) is an interesting challenge.

Another interesting read on the subject of beating the house is The Eudaemonic Pie by Thomas Bass, about a group that built tiny toe-controlled, radio-linked computers into their shoes to solve the dynamics of roulette on the fly. (The book was out of print (but available if you knew where to look), but it looks like it's been reprinted.) While their efforts with roulette didn't pay off directly, the team later applied their ideas to building models for trading derivatives.

Steve Shu, who was FiveSight's "utility infielder" for almost four years (and, although I always kidded about him being the only guy who didn't code, an indispensible part of our team), has moved to Texas with his family, embarked on a new joint venture with his wife, and started blogging his thoughts about management and business.

It's a little odd to be a "startup" that's old enough to have alumni, but I hope Steve's time with us will serve him well in his new endeavors.

Votes have just been counted, and the first real version of the BPEL standard, i.e., the one currently in-process at OASIS, will be called "WS-BPEL 2.0".

(There is still no word on how to pronounce it, however...)

The schemaLocation attribute and its cousin noNamespaceSchemaLocation are used to "suggest" the location or locations of a schema per namespace for validation purposes. The value of the schemaLocation attriubte consists of a list of whitespace-separated pairs of a namespace URI and a location of a schema for elements in that namespace.

For modular documents like WSDL (extensibility via <xsd:any namespace="##other" .../>), this means that the schemaLocation attribute will contain several items. For example, for a WSDL document without extensions, the pair:

http://schemas.xmlsoap.org/wsdl/ http://schemas.xmlsoap.org/wsdl/2003-02-11.xsd

should be present in the schemaLocation attribute. Pairs should also be present for the namespaces used for any extensibility elements. For example, for BPEL partnerLink definitions, the pair

http://schemas.xmlsoap.org/ws/2003/05/partner-link/  http://schemas.xmlsoap.org/ws/2003/05/partner-link/

should also be present. (The first use of the URI is the namespace; the second is a URL for the schema.) The same applies to the SOAP binding, HTTP binding, etc.

This is still only a partial solution, since it doesn't prevent extensibility elements from being used in inappropriate locations, but it's better than letting the extensibility elements fall silently through the ##other hole.