I’m not the only one who thinks XML could be made simpler: XML 2.0 proposal by Elliotte Rusty Harold. At least some of these ideas are good: predefining all the HTML 4.0 entities would be great; getting rid of internal DTD subsets and CDATA sections and leaving validation out of the core spec are winners; building in proper namespace support should have happened already. I’m less sure about others: XSD simple types are way too complicated, but I never felt the need for XML types to match the type system of whatever programming language I happened to be using.

As long as I’m talking about XML, Adam suggested in the comments to my previous post that vendors add complexity to solve the problems of their customers. I responded with another comment, but I’d like to expand on that. I do think that the problems of big enterprise customers are less complicated than most people think. The real problem is that enterprise vendors usually sell to people (executives) who don’t actually use their products, and therefore often base their decisions on check lists of features, so that the vendor claiming the most features wins. YAGNI (“you ain’t gonna need it”) is a losing proposition in this environment, so architects design for every possible contingency, which means things get more and more complicated.

A couple of interesting links via Cameron Moll:

Periodic Table of the (html5) Elements It’s fascinating how similar to the original chemical version this turned out.

Spacelog Original NASA transcripts of early missions, in an easy-to-read and easy-to-link format. (Each individual speech has its own URL.) So far they have Apollo 13 and Mercury 6.

Chris Bowles asked me what I thought about the new design for the University’s home page, and I decided to post my thoughts here.

If you want to get technical, it does a pretty good job on the XKCD test—the only thing I couldn’t find relatively easily was the University police phone number. But it clearly follows the letter rather than the spirit of that cartoon: the big, eye-catching stuff is still about “branding” rather than helping the visitor find what they’re looking for. I’m not saying branding isn’t important, but I’m sure for the vast majority of the people coming to the web site it just gets in their way.

Also, I thought I’d mention that the layout is a bit broken when I view the page in Safari (the browser I use most.) I think this is because I’ve set the preferences to “never use font sizes smaller than 12.” Why do page designers love small fonts so much?

James Clark: XML vs the Web.

You should read the whole thing, but here’s his conclusion:

So what’s the way forward? I think the Web community has spoken, and it’s clear that what it wants is HTML5, JavaScript and JSON. XML isn’t going away but I see it being less and less a Web technology; it won’t be something that you send over the wire on the public Web, but just one of many technologies that are used on the server to manage and generate what you do send over the wire.

My take on XML is that Microsoft and IBM and Software AG and all the other big software vendors took a technology that was originally a simplification of something that had grown over complicated (SGML) and saddled it with layer upon layer of complexity, because then they could sell tools to manage that complexity. In the meantime, people that needed to get stuff done and didn’t have huge budgets for tools moved on to less complicated technologies.

[update] I should probably add that XML is still very useful and won’t go away any time soon, and I don’t regret the effort I’ve put into learning XML technologies. But there’s a lot of junk built on XML—SOAP, UDDI, WS-*, etc.—that could (and should) die unmourned.

Since the 1980’s IBM mainframes have come with a built-in hypervisor that allows you to partition the machine into multiple systems. (As I recall, Amdahl had this feature first.) For over a decade, we’ve run three partitions on the administrative computing system: one partition where we install new versions of the operating system when we receive them from IBM, and make sure it’s working as delivered; a second where we make our local modifications and install third-party applications to test them out; and finally, the production partition that everyone except the systems staff uses. This means that all developer and quality assurance testing occurs in the production partition.

I’ve mentioned this to a few people, but now I’d like to publicly float the idea of breaking up the production partition and spinning out the test and quality assurance environments into their own partitions. The primary advantage of doing so would be a decreased possibility of testing efforts inadvertently affecting production data. (This would particularly apply in batch, where currently developers have to come up with different names for test data sets.) A second advantage would be an enhanced ability to make sure non-production work doesn’t receive an excessive share of the mainframe’s capacity.

The main disadvantage would be slightly more complicated procedures for migrating code and data between environments. Also, setting this up would require some effort, and developers would have to change some of their habits.

So what do y’all think?

I did the early voting thing last week, but today’s the actual election day. And here’s a story about a future election: An Election, by John Scalzi. Here’s a snippet:

“And what do we know about the demographics of the third district?” James asked.

“It’s a human-minority district,” David said. “I know—”

James held up his hand. “How long has it been since a human councilperson held the third district seat?”

“It’s been a few election cycles,” David admitted.

“A few?” James asked.

David threw up his hands. “Fine. It’s been forty-four years,” he said.

As a bit of follow-up to my post the other day about “customer service”, Tim Bray has a post about what you call the people you’re writing software for: No More Users.

I just wrote a little piece about how to write software, and it contained a few references to the humans who carry the mobile devices on which the software runs, and who interact with it. I found myself referring to these individuals as “users” or “the user”. Gack; I hate that word.

In fact, I hate it almost as much as the word “content” which, in the Internet-biz context means “Words and pictures and sounds that you create and I monetize.” Anyone who uses the acronym UGC in my presence should prepare for a nasty reaction.

In the comments, the most popular suggestion is “customers”, but you know how I feel about that. (Although it may be a little better for these people, who may actually be selling their software to their customers.) Anyway, most of the people who use things I write are software developers, so I like to call them … wait for it … “developers”. As for the people they’re writing for, how about calling them “students” or “faculty” or “staff”?

We found out a couple of days ago that there’s a proposal to change policy so that only people working in Operations have card-swipe access to the data centers; the rest of us who work on the machines there will (under the proposed policy) have to be checked in and out by the operators.

Well, this seems like a great idea. Now every time we need to go into the data center we’ll get to stand around and wait for an operator, who will have to interrupt whatever he’s doing to let us in. And what benefit does this provide? It certainly isn’t going to make things any more secure. (The amount of effort being expended on physical security for the data centers already seems way out of proportion to the risks.) It will, however, increase the feeling that management doesn’t trust us or respect our abilities. (And hurt morale, as was so eloquently expressed in yesterday’s ITS all staff meeting.)

Some people seem to have the idea that if you set up sufficient rules you can prevent bad things from happening. This never actually works: as long as you’re doing something, there’s a chance that things will go wrong. The best way to get things done with minimal risk is to trust people but hold them accountable for the results.

This morning we’re having an all-ITS staff meeting, and one of  the agenda agenda items is a breakout session to discuss “Improving ITS customer service.” Which (perhaps inevitably) is the wrong question. When we start thinking of people outside ITS as “customers” rather than friends and colleagues we’re already heading in the wrong direction.

The “customer” label assumes and supports an “us vs. them” point of view. Trying to improve ITS customer service is more about making ITS look good than about advancing the mission of the University. It’s also about avoiding responsibility for the overall success of our projects: “I provided the service you asked for, so if it didn’t work it’s your fault.”

What we need to ask is, “How can we work together with other staff members, faculty, and students to make the University of Texas at Austin the best place in the world to learn, teach, discover new things, and share what we’ve learned and discovered with the people of Texas and the whole human race?” If we could have a vision of how the University can improve the world, and how our own tasks contribute to realizing that vision, the “customer service” issues would disappear.

This past weekend was General Conference for the Church of Jesus Christ of Latter-Day Saints, which means I spent it watching broadcasts from Salt Lake City. In one of his talks, President Monson (the president of the church) referred to a passage in Alice in Wonderland that I think has some application to ITS:

“Cheshire Puss,” she began, rather timidly, as she did not at all know whether it would like the name: however, it only grinned a little wider. “Come, it’s pleased so far,” thought Alice, and she went on: “Would you tell me, please, which way I ought to go from here?”

“That depends a good deal on where you want to get to,” said the Cat.

“I don’t much care where—” said Alice.

“Then it doesn’t matter which way you go,” said the Cat.

Whether we run applications on a mainframe or a Solaris box or a Windows laptop doesn’t make a lot of difference if we don’t know what we want them to accomplish.