Xml use in the browser

C|Net has an article on what people have started calling AJAX. 'A'synchronous JavaScript and Xml. I have seen people using MSXML to build these kinds of web-apps for years, but only recently have people really pulled it all together enough, such as GMail or Outlook Web-Access (OWA). In fact, MSXML's much copied XMLHTTP (a.k.a. IXMLHttpRequest) (Copied by Apple and Mozilla/Firefox) was actually created basically to support the first implementation of OWA.

I've been thinking about what our customers want in future versions of MSXML. What kind of new functionality would enable easier/faster developement of new AJAX style web applications? XForms has some interesting ideas... I've been thinking about what we might add to MSXML to make it easier to develop rich DHtml applications. XForms is an interesting source of ideas, but I worry that it removes too much control. I don't think you could build GMail on XForms, for example.

The most obvious idea, would be to add some rich data-binding. Msxml already has some _very_ limited XML data-binding support. I have not looked much into how OWA or GMail work, but I bet that a significant part of the client-side jscript is code to regenerate the UI from the XML data behind the current page. Anyone who has used ASP/PHP/etc is used to the idea of some sort of loop to generate HTML from some data. What if the browser knew how to do that for you? And knew how to push back changes from editable controls? You can do that today with ADO.

Any other ideas? For those of you playing with 'AJAX' style design. What are the pain points? (Beside browser compatibility... )

InfoSpace, in retrospect

The Seattle Times ran an series last week on the rise and fall of InfoSpace and its charismatic leader, Naveen Jain. A great deal of other people have chimed in on the article, and I really don't have too much to say on the article, InfoSpace, or even Naveen.... except that they were my competing offer when I accepted my position as a developer at Microsoft, 7+ long years ago. InfoSpace was only 20-30(?) people back then. This was long before they went public. That would have been the fall of 1997. I could have had my moments of being a millionaire.

As much as I would have liked the money. I have no regrets. The team I joined at Microsoft has been critical to the adoptions of XML all over this company, as well as across the industry.

cooking that isn't

As long as it has been a potential issue, I've been known amongst my friends for my general inability to cook. 'Inability' is really a bit harsh... more a lack of any desire. I am the mast of the microwave, instant, no-prep meal. Living in a city doesn't help, as I can walk to a plethora of evening options for tasty foods. This isn't to say that I can't cook, so much as that I really have had very little desire to try. When I have made an attempt, I have found that I'm actually pretty good at following recipes. I just don't feel motivated to bother. Food is not exactly a focus of my life. I live alone, and if I am eating at home, I am usually reading while I eat, so the food isn't really the center of my attention.

Last summer I moved into a great house with a great kitchen. After months of jokes about how my bachelorhood manifests itself in my fridge, I decided that I should make a point to try and actually cook every once and a while. This weekend, I made my first foray, sauteing up some shrimp with pasta. yum. Last night, I boiled some asparagus. I'd like to think cooking up a real dinner like this is healthier, but given how much butter and salt I had with the asparagus... I'm not so sure. Better than a frozen pizza anyway.

Powerbook vs Ctrl Key

I may be a programmer working for Microsoft, but I like to think that I can appreciate good design. I also like to experiment, and play with geek toys. Thus my primary personal (i.e. non-work) laptop is an Apple Powerbook (12"). I love that little beast. I use it for web surfing, email, playing DVDs, and managing digital pictures. For that kind of use, the machine rocks. It looks cool, has good battery life, and just does everything quite nicely. It is definitely the best laptop as DVD player that I have ever had, as it is quieter that any PC laptop I have ever owned.

The only activity that I occasionally use it for and which it is deficient compared to my Dell Latitude, is programming. Why? The control key. When I'm programming, my fingers are glued to the keyboard. I'm not much of a mouse user anyway, but programming is all about text, so use the mouse even less when writing/debugging/etc code. The problem is that every programming environment I've ever used (yes, even vi) depends heavily on the control key. Since I switch constantly between a desktop keyboard, my Dell Latitude, and my Powerbook, I need a consistent layout, or my poor fingers get all confused. All my keyboards except the Powerbook, that the control key as a nice big key way in the bottom left corner. Very easy to find with my little finger. On my Powerbook, that is the Fn key! There are a number of tools for swapping around control and capslock (sort-of... actually, there doesn't appear to exist a tool to swap control and capslock, just ways to make capslock act like control...) but it appears that the Fn key is hardwired into the keyboard's hardware.

I know that Apple is targeting designer/artsy type people, but this is just really annoying. It tends to mean that every time I pick up a laptop to try out some programming idea I had, I pick up my wintel laptop. A number of people have commented that Apple is luring people away from Linux. I bet this one simple design decision for the PowerBook will turn a measurable percentage of the key potential contributor away.

blog as quick-n-dirty background check

One of the interesting side effects of my taking up blogging, is that people can find out more information about me via Google/etc. I've been made very aware of this recnetly, as I've had a number of women I've met look me up in Google. It is very strange to have women I have only recently met, comment on my blog. Lucky for me, they seem to be impressed, rather than turned-off/scared/something-else. Probably not just luck, since I tend date intelligent, slightly geekier (in the cutest way.. honest!) women. Still, it is odd to realize that women are using my web presence as something that ammounts to a background check. What if someone somewhere decided they didnt like me, and started publishing negative comments about me? It is scary to realize that one's reputation is so vulnerable to attack, with little real recourse. Then again, the beaty of the internet is that it tends to be its own counter-balance. If there is someone out there decrying my horrid morals, there is likely a person calling that person a liar or at least providing some level of counterpoint. The more you are involved, the more counter-counter-counter-points there are.

So far so good, for me at least. If only online-dating sites worked so well.

Serving Many Masters

After spending a great deal of time involved in discussions about various XML data-models (Infoset, DOM, XPath, XQuery, etc) and a morass of issues related to trying to add edit support to our XPathNavigator API in System.Xml, I found my self pondering XML APIs. Despite the fast that Elliotte Rusty Harold and I have disagreed in the past, a number of the point he brings up in his What’s Wrong with XML APIs (and how to fix them) presentation are very good. I found that rather that doing anything useful, I kept pondering what shape my API would take. One of the first things I worked on here at Microsoft was our XML DOM, and I've spent years helping internal and external customers understand how to get the best out of it. When I started here, I came from a SGML background, and spent a lot of time explaining why mixed content was so important. A lot of people who just pick up XML as a tool, rather than a core part of teir work, are using XML files as simplified databases. To them, mixed content is a very odd notion. Worse, they are often surprised at how whitespace, mixed content, and a few other tricky aspects of XML, reveal themselves in the DOM. So I started pondering how I would design an API that was better balanced for these users.

The problem is that you don't really want two totally different APIs, for related user scenarios. The problem is that a lot of customers don't really know what they want when they first start out using a new technology. They haven’t had enough experience with the technology and their use-cases to know all the ins and outs. XML has demonstrated itself to be unfortunately bad in this. Customers think they only need to worry about X (some simplified subset of XML) until 2 weeks before ship, when someone points out that they have been completely ignoring xml-namespaces / whitespace / mixed-content / processing-instructions / etc... I have seen this time and time again.

So you really want an API that lets people who don't really care about 'markup', just deal with the higher level structure, yet provides convenient access to the 'markup', for those who do need it. Worse, that 'higher level structure' I mentioned is something different to different customers. Remember those multitude of different data-models I mentioned earlier? So how do you service both customers?

Honestly, I don't have an answer. We have the DOM today, and a lot of this can be avoided by using XPath to navigate the DOM (selectSingleNode and selectNodes in both Microsoft's MSXML and System.Xml implementations). XOM definitely looks better than the DOM, but is it enough better to justify replacing the DOM with something like it? I don’t think so. The disadvantage to being Microsoft, is that once you decide to do something like that, it is institutionalized. Unless we can define an API which is so much better that it worth your while to abandon the DOM and port existing code (just for the benefit of those new features you are writing...) to the new API, then it just doesn't seem worth adding a new API, just because it is slightly better.

The problem is that XML, as a standard, and thus any XML API, serves many, many masters. Different customers have different needs, and the XML standard is open enough that they all feel included. To define an API which excludes too many users, implies that it will be destined to be just a niche API. Trying to define an API which allows full markup fidelity (a'la DOM/XmlReader/etc) seems destined to be just as full of traps for the XML neophyte as XML itself is. Trying to define a simplified API that targets the 80% usage (SOAP oriented scenarios for example) conversely rules out some of that very features that the XML 'experts' depend on.

I fear, this is a question to which there is no easy answer.

post-busy

I've been rather busy lately. We are finishing up System.Xml for Whidbey Beta-2 and Msxml for Yukon Beta-3, and since I manage both dev teams... I've been rather busy.

I hope to have more time to contribute to my blog in the near future. I've got lots to babel about... music, programming, previously mentioned release, pruning-shrubs, parents-visiting... yea, I've got a lot I could talk about, so I definitely hope to be able to update this blog a bit more often this month.

and shouts out to my sister! I'm the proud uncle of Toby Johnson. Heather, you never cease to amaze me! Toby, see you soon! (aka... I plan to spoil you rotten, just because I can, blessed be those 3 some thousand miles between your regular life an mine...)