Sean Campbell or Scott Swigart writes

I want this also.  I want a theory that unifies objects and data.  We're not there yet.

 With a relational database, you have data and relationships, but no objects.  If you want objects, that's your problem, and the problem isn't insignificant.  There’s been a parade of tools and technologies, and all of them have fallen short on the promise of bridging the gap.  There's the DataSet, which seeks to be one bucket for all data.  It's an object, but it doesn't give you an object view of the actual data.  It leaves you doing things like ds.Tables["Customer"].Rows[0]["FirstName"].ToString().  Yuck.  Then there are Typed DataSets.  These give you a pseudo-object view of the data, letting you do: ds.Customer[0].FirstName.  Better, but still not what I really want.  And it's just code-gen on top of the DataSet.  There's no real "Customer" object here.

 

Then, there are ObjectSpaces that let you do the XSD three-step to map classes to relational data in the database.  With ObjectSpaces you get real, bona fide objects.  However, this is just a bunch of goo piled on top of ADO.NET, and I question the scalability of this approach. 

 

Then there are UDTs.  In this case, you've got objects all the way into the database itself, with the object serialized as one big blob into a single column.  To find specific objects, you have to index the properties that you care about, otherwise you're looking at not only a table scan, but rehydrating every row into an object to see if it's the object you're looking for.

 

There's always straight XML, but at this point you're essentially saying, "There are no objects".  You have data, and you have schema.  If you're seeing objects, it's just an optical illusion on top of the angle brackets.  In fact, with Web services, it's emphatically stated that you're not transporting objects, you're transporting data.  If that data happens to be the serialization of some object, that's nice, but don't assume for one second that that object will exists on the other end of the wire.

 

And speaking of XML, Yukon can store XML as XML.  Which is to say you have semi-structured data, as XML, stored relationally, which you could probably map to an XML property of an object with ObjectSpaces.

 

What happens when worlds collide?  Will ObjectSpaces work with Yukon UDTs and XML?

 

Oh, and don't forget XML Views, which let you view your relational data as XML on the client, even though it's really relational.

 

<snip />

 

So for a given scenario, do all of you know which technology to pick?  I'm not too proud to admit that honestly I don't.  In fact, I honestly don't know if I'll have time to stress test every one of these against a number of real problem domains and real data.  And something tells me that if you pick the wrong tool for the job, and it doesn't pan out, you could be pretty hosed. 

Today we have a different theory for everything.  I want the Theory of Everything.

I've written about this problem in the past although at the time I didn't have a name for the Theory of Everything, now I do. From my previous post entitled Dealing with the Data Access Impedance Mismatch I wrote

The team I work for deals with data access technologies (relational, object, XML aka ROX) so this impedance mismatch is something that we have to rationalize all the time.

Up until quite recently the primary impedance mismatch application developers had to deal with was the Object<->Relational impedance mismatch. Usually data was stored in a relational database but primarily accessed, manipulated and transmitted over the network as objects via some object oriented programming language. Many felt (and still feel) that this impedance mismatch is a significant problem. Attempts to reduce this impedance mismatch has lead to technologies such as object oriented databases and various object relational mapping tools. These solutions take the point of view that the problem of having developers deal with two domains or having two sets of developers (DB developers and application coders) are solved by making everything look like a single domain, objects. One could also argue that the flip side of this is to push as much data manipulation as you can to the database via technologies like stored procedures while mainly manipulating and transmitting the data on the wire in objects that closely model the relational database such as the .NET Framework's DataSet class.

Recently a third player has appeared on the scene, XML. It is becoming more common for data to be stored in a relational database, mainly manipulated as objects but transmitted on the wire as XML. One would then think that given the previously stated impedance mismatch and the fact that XML is mainly just a syntactic device that XML representations of the data being transmitted is sent as serialized versions of objects, relational data or some subset of both. However, what seems to be happening is slightly more complicated. The software world seems to moving more towards using XML Web Services built on standard technologies such as HTTP, XML, SOAP and WSDL to transmit data between applications. And taken from the WSDL 1.1 W3C Note

WSDL recognizes the need for rich type systems for describing message formats, and supports the XML Schemas specification (XSD) [11] as its canonical type system

So this introduces a third type system into the mix, W3C XML Schema structures and datatypes. W3C XML Schema has a number of concepts that do not map to concepts in either the object oriented or relational models. To properly access and manipulate XML typed using W3C XML Schema you need new data access mechanisms such as XQuery. Now application developers have to deal with 3 domains or we need 3 sets of developers. The first instinct is to continue with the meme where you make everything look like objects which is what a number of XML Web Services toolkits do today including Microsoft's .NET Framework via the XML Serialization technology. This tends to be particularly lossy because traditionally object oriented systems do not have the richness to describe the constraints that are possible to create with a typical relational database let alone the even richer constraints that are possible with W3C XML Schema. Thus such object oriented systems must evolve to not only capture the semantics of the relational model but those of the W3C XML Schema model as well. Another approach could be to make everything look like XML and use that as the primary data access mechanism. Technologies already exist to make relational databases look like XML and make objects look like XML. Unsurprisingly to those who know me, this is the approach I favor. The relational model can also be viewed as a universal data access mechanism if one figured out how to map the constraints of the W3C XML Schema model. The .NET Framework's DataSet already does some translation of an XML structure defined in a W3C XML Schema to a relational structure.

The problem with all three approaches I just described is that they are somewhat lossy or involve hacking one model into becoming the uber-model. XML trees don't handle the graph structures of objects well, objects can't handle concepts like W3C XML Schema's derivation by restriction and so on. There is also a fourth approach which is endorsed by Erik Meijer in his paper Unifying Tables, Objects, and Documents where one creates a new unified model which is a superset of the pertinent features of the 3 existing models. Of course, this involves introducing a fourth model.

The fourth model mentioned  above is the unified theory of everything that Scott or Sean is asking for. Since the last time I made this post, my friend Erik Meijer has been busy and produced another paper that shows what such a unification of the ROX triangle would look like if practically implemented as a programming language in his paper Programming with Circles, Triangles and Rectangles. In this paper Erik describes the research language Xen which seems to be the nirvana Scott or Sean is looking for. However this is a research project and not something Sean or Scott will be likely to use in production in the next year.

The main problem is that Microsoft has provided .NET developers with too much choice when it comes to building apps that retrieve data from a relational store, manipulate the data in memory then either push the updated information back to the store or send it over the wire. The one thing I have learned working as a PM on core platform technologies is that our customers HATE choice. It means having to learn multiple technologies and make decisions on which is the best, sometimes risking making the wrong choice. This is exactly the problem Scott or Sean is having with the technologies we announced at the recent Microsoft Professional Developer Conference (PDC) which will should be shiping this year. What technology should I use and when I should I use it?

This is something the folks on my team (WebData - the data access technology team) know we have to deal with when all this stuff ships later this year which we will deal with to the best of our ability. Our users want architectural guidance and best practices which we'll endeavor to make available as soon as possible.

The first step in providing this information to our users are the presentations and whitepaper we made available after PDC, Data Access Design Patterns: Navigating the Data Access Maze (Powerpoint slides) and Data Access Support in Visual Studio.NET code named “Whidbey”. Hopefully this will provide Sean, Scott and the rest of our data access customers with some of the guidance needed to make the right choice. Any feedback on the slides or document would be appreciated. Follow up documents should show up on MSDN in the next few months.

From ThinkGeek

Skillset Exportable
Insufficient ROI
Office of Employee Termination and Overseas Outsourcing

Definitely wouldn't mind rocking this around the B0rg cube.

Joi Ito recently added a link to a CSS style information to the content in his RSS feed. This broke a number of news aggregators because his stylesheet clashed with whatever styles were being used by various client aggregators. As Sam Ruby points out RSS Bandit strips out such tags completely so we don't have this problem.

We started stripping certain [X]HTML tags for security reasons after I read Mark Pilgrim's article on "How To Consume RSS Safely". Since then I've recanted on striping certain tags now that we use the browser's security settings to decide whether to load ActiveX controls, execute Javascript or even load external images. However I still plan to strip style tags because RSS Bandit's XSLT themes would render quite hideously if we loaded CSS stylesheets defined in the feed in combination with them. Just imagine what would happen if I combined the style definitions in random feeds with RSS Bandit's Outlook 2003 theme, Halloween theme, or Unwise Terminal theme. Ugh.

Oleg Tkachenko writes

The goals of exposing comments are: enabling for arbitrary RSS reader application to see comments made to blog items and to post new comments. There are several facilities developed by RSS commutity, which allow to achieve these goals:

1. <slash:comments> RSS 2.0 extension element, which merely contains number of comments made to the specified blog item.
2. RSS 2.0 <comments> element, which provides URI of the page where comments can be viewed and added (it's usually something like http://yourblog/cgi-bin/mt-comments.cgi?entry_id=blog-item-id in MT blogs).
3. <wfw:commentRss> RSS 2.0 extension element, which provides URI of comment feeds per blog item (to put it another way - returns comments made to specified blog item as RSS feed).
4. <wfw:comment> RSS 2.0 extension element, which provides URI for posting comments via CommentAPI.

It works like a charm. Now users of SharpReader and RSS Bandit can view the comments to posts in Oleg's MovableType blog directly in their aggregator. Posting comments from RSS Bandit works as well. Hopefully, this will catch on and folks no longer have to choose between .TEXT and  dasBlog (i.e. ASP.NET/Windows based blogging tools) when they want a blog tool that supports exposing comment in their RSS feed. The more the merrier.

This document specifies the "feed" URI (Uniform Resource Identifier) scheme for identifying data feeds used for syndicating news or other content from an information source such as a weblog or news website. In practice, such data feeds will most likely be XML documents containing a series of news items representing updated information from a particular news source.

The purpose of this scheme is to enable one click subscription to syndication feeds in a straightforward, easy to implement and cross platform manner. Support for one click subscription using the "feed" URI scheme is currently supported by NetNewsWire, Shrook, SharpReader and RSS Bandit. The author of NewsGator has indicated that support for one click subscription using the "feed" URI scheme will exist in next version.

Any feedback on the draft specification would be appreciated.

Update: Graham Parks has pointed out in the comments to this post that URIs of the form "feed://http://www.example.com/rss.xml" are not compliant with RFC 2396. This will be folded into the next draft of the spec.

Chris Sells recently complained that a recent interview of Don Box by  Mary Jo Foley is "a relatively boring interview" because "Mary Jo doesn't dig for any dirt and Don doesn't volunteer any". He's decided to fix this by proposing an alternate interview where folks send in their favorite questions and he picks the 10 best and formwards them to Don (kinda like Slashdot interviews). Chris offers some seed questions but they are actually much lamer than any of the ones Mary Jo asked so I suspect his idea of questions that dig for dirt are different from mine.

I drafted 10 questions and picked the 3 least controversial for my submissions to the Don Box interview pool.

1. People often come up with euphemisms for an existing word or phrase that has become "unpleasant" which although technically mean a different thing from the previous terminology are used interchangeably. A recent example of this is the replacement of "black" with "African American" in the modern American lexicon when describing people of African descent.

   I suspect something similar has happened with XML Web Services and Service Oriented Architecture. Many seem to think that the phrases are interchangeable when on the surface it seems the former is just one instance of the latter. To you what is the difference between XML Web Services and Service Oriented Architectures?

2. For a short while you were active in the world of weblogging technologies, you tried to come up with an RSS profile and were working on a blogging tool with Yasser Shohoud and Martin Gudgin. In recent times, you have been silent about these past activities. What sparked your interest in weblogging technologies and why does that interest seem to have waned?

3. What team would you not want to work for at Microsoft and why?

These were my tame questions but I get to hang with Don sometime this week so I'll ask him some of the others in person. I hope one of my questions gets picked by Chris Sells.

Where else do you get to see movie clips of illustrious American celebrities in ads for household products they wouldn't be caught doing in the United States? Japander.com, of course. The front page of the website reads

Pander:n., & v.t. 1. go-between in clandestine amours, procurer; one who ministers to evil designs. 2 v.i. minister (to base passions or evil designs, or person having these)

Japander:n.,& v.t. 1. a western star who uses his or her fame to make large sums of money in a short time by advertising products in Japan that they would probably never use. ~er (see synecure, prostitute) 2. to make an ass of oneself in Japanese media.

The clips are all crazy weird from Arnold Schwarznegger pimping energy drinks and cup o' noodles to Mel Gibson, Antonio Banderas  & Kevin Costner as Subaru pitchmen. I probably spent 30 minutes marvelling at the ads on the site, I definitely never thought I'd ever see Harrison Ford doing beer commercials. Definitely entertaining stuff.  

Just stumbled on the following article entitled So, Scrooge was right after all

Conventional economics teaches that gift giving is irrational. The satisfaction or "utility" a person derives from consumption is determined by their personal preferences. But no one understands your preferences as well as you do.

So when I give up $50 worth of utility to buy a present for you, the chances are high that you'll value it at less than $50. If so, there's been a mutual loss of utility. The transaction has been inefficient and "welfare reducing", thus making it irrational. As an economist would put it, "unless a gift that costs the giver p dollars exactly matches the way in which the recipient would have spent the p dollars, the gift is suboptimal".

The big problem I've always had with economics as I was always taught in school is that the fundamental assumption underlying it is that humans make rational decisions when buying and selling goods and services. This is simply not true. The above example is a good one; it makes more sense for everyone involved in the annual gift exchange that is Christmas if people just gave checks and gift certificates instead of buying gifts that the recipients don't want or don't need. Yet this isn't how Christmas gift giving is done in most cases. Then there's the entire field of advertising with its concept of lifestyle ads which are highly successful and are yet another example that human buying decisions aren't steeped in rationality.

What a crock...

An article in the Economist lets us know that research has confirmed that men lose their fiscal prudence in the presence of attractive women

Over 200 young men and women participated in the study, which was divided into three parts. In the first, the participants were asked to respond to nine specific choices regarding potentially real monetary rewards. (At the end of the session, they could roll dice to try to win one of their choices, which would be paid by an appropriately post-dated cheque issued by the university.) In each case, a low sum to be paid out the next day was offered against a higher sum to be paid at a specified future date. Individual responses were surprisingly consistent, according to Dr Wilson, so the “pre-experiment” threshold of each participant was easy to establish.

The volunteers were then asked to score one of four sets of pictures for their appeal: 12 attractive members of the opposite sex; 12 non-lookers; 12 beautiful cars; or 12 unimpressive cars. Immediately after they had seen these images, they were given a new round of monetary reward choices.

As predicted, men who had seen pictures of pretty women discounted the future more steeply than they had done before—in other words, they were more likely to take the lesser sum tomorrow. As Dr Wilson puts it, it was as though a special “I-want-that-now” pathway had been activated in their brains. After all, the money might come in handy immediately. No one else was much affected. (Women did seem to be revved up by nice cars, a result the researchers still find mystifying. But the statistical significance of this finding disappeared after some routine adjustments, and in any case previous work has suggested that women are more susceptible to displays of wealth than men are.)

I guess this explains Abercrombie & Fitch's "alleged" hiring practices. It's always interesting to see stuff you've long taken for granted backed up by research especially observing how the experiments are confucted.

Slashdot has posted a link to Eric Sink's "Make More Mistakes" article on MSDN. One of the anecdotes from the article reads as follows

Circa 1998, betting on Java for a graphical user interface (GUI) application was suicidal. The platform simply didn't have the maturity necessary for building quality user interfaces. I chose Java because I was "head over heels" in love with it. I adored the concept of a cross-platform C-like language with garbage collection. We were hoping to build our Java expertise and make this exciting new technology our specialty.

But Java turned out to be a terrible frustration. The ScrollPane widget did a lousy job of scrolling. Printing support routinely crashed. The memory usage was unbelievably high.

I should have gotten over my religious devotion to semicolons and done this app in Visual Basic.

Lesson learned: Be careful about using bleeding-edge technologies.

There are some on Slashdot who think that Eric learned the wrong lesson from that experience. This post entitled Alteration of rule is from a developer who was in a similar circumstance as Eric but had a different outcome

I built a Java/Swing app around the same time. It was a pretty complex user app, not just a simple program - and we managed to completely satisfy the clients and make the program perform acceptably on a very low-end target platform (PII-133 with 32 MB of memory). For what he described (replacing a complex spreadsheet) he should have been able to complete the task.

Why did our app work and his fail? Because we knew Java and Swing well by that point, and knew what was possible with some time spent optimizing. We had a plan in our head for how to reach a target level of performance that would be accepted and more than met that goal.

The lesson he should have learned was "Know your technology well before you embark on a project". The reason why it's so important to learn THAT lesson is that it applies to any project, not just ones using "bleeding edge" technologies. The only difference between an established and bleeding edge technology is the level of support you MIGHT be able to find. And that is not enough of a difference to totally affect either failure or success.

I tend to agree with the Slashdot post. Learning on the job is fine and all but when big bucks is on the line its best to go with what you are familar with especially if it is tried and tested.