Critters Just Shelley

What were they thinking?

Zoë had to go in for a rather intensive physical today. She’s always been somewhat of a gorger, chomping down her dry food too fast and than… know. Lately it seems to happen more frequently and we thought it was time to check her out, make sure she’s OK.

Zoë’s also moving with more difficulty. When she walks down the stairs in the morning, she hops down, keeping her back legs together.

The vet tried to listen to her heart and thought she heard a murmur. To check for sure, she got an EKG, which is kind of cute (if not inexpensive). The worst of it, though, was getting a blood sample.

Zoë is the sweetest cat in the world, but she hates vets. One we had would examine her without assistance until the day when Zoë actually scratched the stainless steel of the examining table. The doctor jumped back, held his arms up, exclaiming, “Whoa!”

Now she gets a vet, two assistants, and being wrapped in The Blanket. Well, and today she got a muzzle for the first time, too. It’s good to know Zoë still has her teeth.

I’m not happy with the vet right now, and it wasn’t necessarily because of the muzzle. They shaved Zoë’s neck to get a blood sample, but she fought so much they decided to get the sample from her leg. A shaved neck and three shaved legs, they got their sample. Since the legs were still bleeding what did they do? They put gauze over the puncture wounds, and wrapped each leg with adhesive medical tape.

Do you know how hard it is to get tape out of a cat’s fur? Especially when it hurts the cat? My roommate and I finally succeeded, but not before our little girl was further traumatized. I think it’s time to find another vet.

Zoë is now on arthritis medication; one of the first real signs of her advancing age. According to the charts, she’s equal to a 75 year old human but she still plays On the Back of the Chair monster, chases the bird toy around the top of the bed, plays keep-away.

JavaScript RDF

To JSON or not to JSON

Recovered from the Wayback Machine.

Dare Obasanjo may be out of some Ajax developers spheres….actually *I’m probably out of most Ajax developers spheres…but just in case you haven’t seen his recent JSON/XML posts, I would highly recommend them:

The GMail Security Flaw and Canary Values, which provides some sound advice for those happily exposing all their vulnerable applications to GET requests with little consideration of security. I felt, though, that the GMail example was way overblown for the consternation it caused.

JSON vs. XML: Browser security models. This gets into the cross-domain issue, which helped increase JSON’s popularity. Before you jump in with “But, but…” let me finish the list.

JSON vs. XML: Browser Programming Model on JSON being an easier programming model. Before you jump in with “But, but,…” let me finish the list.

XML has too many Architect Astronauts. Yeah, if you didn’t recognize a Joel Spolskyism in that title, you’re not reading enough Joel Spolsky.

In the comments associated with this last post, a note was made to the effect that the cross-domain solution that helped make JSON more popular doesn’t require JSON. All it requires is to surround the data returned in curly brackets, and use the given callback function name. You could use any number of parameters in any number of formats, including XML, as long as its framed correctly as a function parameter list.

As for the security issues, JSON has little to do with that, either. Again, if you’re providing a solution where people can call your services from external domains, you better make sure you’re not giving away vital information (and that your server can handle the load, and that you ensure some nasty bit of text can’t through and cause havoc).

I’ve seen this multiple places, so apologies if you’ve said this and I’m not quoting you directly, but one thing JSON provides is a more efficient data access functionality than is provided by many browser’s XML parsers. Even then, unless you’re making a lot of calls, with a lot of data, and for a lot of people, most applications could use either JSON or XML without any impact on the user or the server. I, personally, have not found the XML difficult to process, and if I wanted really easy data returns, I’d use formatted HTML–which is another format that can be used.

You could also use Turtle, the newly favored RDF format.

You could use comma separated values.

You could use any of these formats with either the cross-domain solution, or using XMLHttpRequest. Yes, really, really.

As was commented at Dare’s, the cross-domain issue is not dependent on JSON. HOWEVER, and this one is worthy of capitals: most people ASSUME that JSON is used, and you’re not returning JSON, you better make sure to emphasize that a person can a) choose the return format (which is a superior option), and/or b) make sure people are aware if you’re not using JSON by default with callback functions.

As for using JSON for all web service requests, give us a break, mate. Here’s a story:

When the new bankrupty laws were put into effect in the year 2005, Congress looked around to find some standard on which to derive ‘reasonable’ living costs for people who have to take the new means test. Rather than bring in experts and ask for advice, their eyes landed on the “standards of living expenses” defined by the IRS to determine who could pay what on their income tax.

The thing is, the IRS considers payment to itself to probably be about as important as buying food and more than paying a doctor. The IRS also did not expect that their means test would be used by any other agency, including Congress to define standards for bankruptcy. The IRS was very unhappy at such when it was discovered.

In other words, just because it ‘works’ in one context doesn’t mean it works well in all contexts: something that works for one type of application shouldn’t be used for all types of applications. Yes, ECMAScript provides data typing information, but that’s not a reason to use JSON in place of XML. Repeat after me: JavaScript/ECMAScript is loosely typed. I’m not sure I’d want to model a data exchange with ‘built-in typing’ based on a loosely typed system.

Consumers of JSON or XML (or comma separated values for that matter) can treat the data they receive in any way they want, including parsing it as a different data type than what the originator intended. Yes, JSON brings a basic data typing, and enforces a particular encoding, but for most applications, we munge the returned data to ensure it fits within our intended environment, anyway.

What’s more important to consider is: aren’t we getting a little old to continually toss out ‘old reliables’ just because a new kid comes along? I look at the people involved in this discussion and I’m forced to ask: is this a guy thing? Toss out the minivan and buy the red Ferrari? Toss out the ‘old’ wife for a woman younger than your favorite shirt? Toss out old data formats? Are the tools one uses synonymous with the tools we have?

Snarky joking aside and channeling Joel Spolsky who was spot on in his writing, just because a new tech is sexy for it’s ‘newness’ doesn’t mean that it has to be used as a template for all that we do.

The biggest hurdle RDF has faced was it’s implementation in XML. It’s taken me a long time to be willing to budge on only using RDF/XML, primarily because we have such a wealth of tools to work with XML, and one can keep one’s RDF/XML cruft-free and still meaningful and workable with these same tools. More importantly, RDF/XML is the ‘formal’ serialization technique, and there’s advantages to knowing what you’re going to get when working with any number of RDF APIs. However, I have to face the inevitable in that people reject RDF because of RDF/XML. If accepting Turtle is the way to get acceptance of RDF, then I must. I’d rather take another shot at cleaning up RDF/XML, but I don’t see this happening, so I must bow to the inevitable (though I only use RDF/XML for my own work).

We lose a lot, though, going with Turtle. We loose the tools, the understanding, the validators, the peripheral technologies, and so on. This is a significant loss, and I’m sometimes unsure if the RDF community really understands what they’re doing by embracing yet another serialization format for yet another data model.

Now we’re doing the same with JSON. JSON works in its particular niche, and does really well in that niche. It’s OK if we use JSON, no one is going to think we’re only a web developer and not a real programmer if we use JSON. We don’t have to make it bigger than it is. If we do, we’re just going to screw it up, and then it won’t work well even within that niche.

Flickr and other web services let us pick the format of the returned data, Frankly, applications that can serve multiple formats should provide such, and let people pick which they use. That way, everyone is happy.

Ajaxian: Next up: CSV vs. Fixed Width Documents. *snork*

*most likely having something to do with my sense of humor and ill-timed levity.


Dare to stay

Recovered from the Wayback Machine.

A piece of good news, Dare Obasanjo has decided not to pack in his weblog and proceeded to demonstrate such by posting several very helpful posts on the recent GMail scandal (which, all things considered, wasn’t that much of a scary situation–oh, we’ll get more spam, horrors.)

As an aside, sometimes when I write something that I somewhat regret writing, because it’s too sentimental or exposes too much, I write several blog posts, one right after the other, to ‘push’ the vulnerable post down and out of the page. I wonder if other people do this?

Anyway, Dare wrote some useful stuff on the vulnerability of GETs mixed with JSON, especially for Ajax developers.