Triple XXX

BoingBoing ran a story today on Triple XXX, a restaurant in West Lafayette, IN, which is where Purdue is located. Which is where I went to college.

Very popular place to go late at night, after drinking way too much beer, to get a burger and onion rings. Lots of folks liked the Duane Purvis, including Sandy, but the peanut butter was a little over the top for me. I usually got the Bert Burger, or maybe eggs, or sausage gravy, depending on how close to dawn it was (or past).

My senior year, I rented a house with 6 friends, on Littleton Street, across from the hugemongous frats, about 5 houses down from Triple XXX. It was very convenient. I remember at the end of fall semester, no one had enough money to pay for a big shopping trip, so we just stopped shopping. And ate at Triple XXX a lot; except on Tuesdays; 25 cent tacos at Taco Bell on Tuesdays.

In the picture above (click the picture for a slightly larger version), circa 1960, you can just barely see the sign for the Clark gas station under the car cover. That's where we'd buy our cigs. I was there in the 80's; besides the cars, it looks pretty much the same.

I think we used to call the restaurant Tri Chi, but looking at the name now, it's funny that it's called Triple XXX, when we pronounced the name "Triple X". Not "Triple X X X". Which would have been way too long. Wouldn't Triple XXX be XXXXXXXXX?

I love in the picture above they have to make a point to show the restaurant is not an 'adult' restaurant (whatever that might mean).

Gonna have to get me a shirt!

Comments enabled

I decided to enable comments; previously, I had specifically disabled them. I'm not a big fan of commenting in blogs, because without a nice interface to let me track who responds to comments I make, it's not really worth it. I really don't want to have to go back to someone's blog web site to check. I'm sure that will change some day.

In the meantime, I got a couple emails this weekend from some folks at IBM concerning my posts on VMware. I figure I might as well be a little nice about it, and let people post comments instead of having to find an email address of mine.

BTW, Russell and Karl, I posted the links you sent in my del.icio.us links. Thanks again.

Actually, I noticed on /. today that apparently VMware has a free server available now as well as the player (as a beta). Sigh. There just aren't enough hours in the day.

Attributes vs. Elements

This is a response to Bill Higgins' blog post titled Simplicity for humans, simplicity for programs.

IIRC, when Balaji was designing the new marshaller, I specifically told him that I wanted everything marshalled as subelements and not attributes. Why would I do this? It had nothing to do with readability; I requested this because the marshalling scheme we were replacing was agressively using attributes instead of subelements. Including doing things like marshalling a list of things as a comma-separated string used as an attribute value. That was way wrong. Since it forced folks to have to do further parsing even after parsing up the XML.

The decision on whether to marshall something as an attribute or subelement is usually not too difficult. If the value can be represented as a short-ish string, an attribute works out well. If it's a string and long-ish, using a subelement might be better (and allow you to handle in-line markup on that, or microformats, or ...). If it's data with it's own structure, you'll want to use subelements.

If you are representing a list of things, you really want subelements, although then you have more decisions to make. Should you add a special containing element, like a <ul> element, and render the list items as subelements under that? Or should you not have a containing element, and store each item as a peer of other elements in the same structure. Maybe you want to use a containing element, but that element name is the 'property' name, and the list elements are stored as <li> elements.

In the end, you end up with this weird tension of wanting to use attributes as much as possible, since they are easier for programs to get to, they take up less text, etc. But then you end up having the remainder of your things that you have to render as subelements, for whatever reason. The decision ends up being made strictly on whether XML can actually handle it as an attribute, and that seems wrong.

Thus, I decided that rather than make somewhat arbitrary decisions about whether to use attributes or subelements, and then make people guess at which we'd use when they saw the programs that ate this data, to go with the lowest common denominator; nothing but subelements. Of course, even that's not quite right; we actually do have a small fixed set of things we render as attributes. Very small.

The fact that you have to make decisions like this, even about whether to render something as an element or attribute, speaks to the problems here. XML is great for documents, but what you are really talking about is data. Do we need to describe all our data as documents? If noone is ever going to need it as a document, why go to that trouble? Is XML a solution in search of a problem in this case?

If you don't have a real requirement to provide a document for your data, other formats like JSON might be more appropriate.