An Opinion blog

My Links

Story Categories

Archives

Post Categories

Image Galleries

Login


Remember

Disclaimer

This site is operated by Mike Deem. The opinions expressed here are mine. They are not necessarily my employer's or anybody else's.

Wednesday, November 19, 2003 #

All Pretty But One

About my posts, Sam Gentile says “Most are worth reading.” Now I'm just dying to know which ones aren't. Maybe this one.

posted @ 11:14 PM | Feedback (1)

Warm Fuzzy

People have been asking me for days if I have read Ray Ozzie's post on WinFS. I finally took the time read it slowly and enjoy. Makes me feel good about what I'm working so hard to accomplish.

But you know what... posts like Matthew Mastracci's are the really valuable ones. Challenging our assumptions. There are some interesting comments in Robert Scoble's response as well.

A few specific points:

1) “...I can't see how calling the WinFS APIs is any different than calling the vCard/EXIF/ID3 APIs directly”: Each of those APIs (if you can call a file format an API) is different. The WinFS API provides a common programming model for working with all kinds of meta-data. This programming model fits in with the rest of WinFX, creating yet another kind of network effect resulting in increased programmer productivity. Also note that WinFS doesn't devalue these formats, it just provides a common way to program and search them.

2) “How does the record executive get his contact for 'Marvin Gaye' to link to a list of albums and lyrics, while ensuring that my friend Marvin Gaye's address isn't associated for any of the same things.”: Yep, this is one of our hard questions. What fault is there in WinFS for trying to solve this problem or even simply providing a platform that can be used by an ISV to solve the problem?

3) “The existance of an open data format doesn't mean that your favorite (or mission-critical) application stores its data in the open!”: But providing a simple standard store that is integrated with the shell and many Windows applications will provide a reason for such mission-critical applications to use WinFS for “offline” scenarios. WinFS security will make this data at least as secure as saving it an XML document, an Excel spreadsheet or an Access database, which is what people do with this data today when they go on a business trip.

4) “What I see in WinFS is the Windows-centric design philosophy”: Yes. So? We are investing a lot in making Windows the best platform out there. If it ends up being better then Linux... sorry. But I don't buy into the second part of the statement: everyone is using Windows, so we can just assume that all of their data will be somewhere in the Windows domain!” The WinFS sync infrastructure will allow data to be moved into and out of WinFS as needed. The back end data sources don't have to be Windows. The work we are doing to support XML data in WinFS is also an indication that we don't believe all data is somewhere in the Windows domain.

posted @ 11:11 PM | Feedback (0)

WinFS Schema Language

In his recent interview with Jonathan Schwartz, Steve Gillmor makes the statement that “XSD [is] being baked into Office, but is being deprecated in favor of a new schema structure for WinFS.” This reflects some statements by Jon Udell. Dare had what I thought was a good response, and John Montgomery posted my opinion on this before I had my blog setup.

I'll say it as plainly as I can: the choice to not use XSD to describe WinFS types in no way deprecates the use of XSD to describe XML documents or data.

For a number of really good reasons we decided early on that the that first class things WinFS would store would be items, relationships, and extensions not XML elements and attributes. As such, we needed a language to describe our items, relationships and extensions. Trying to do this with XSD was sort of like trying to describe dance movement using the language of physics.

Sure, we could have used some sort of XSD + Annotations - Features We Can't Support. But this is also a bad idea and would result in other kinds of criticism. It is interesting that nobody is saying we should have used a modified SQL grammar (CREATE ITEMTYPE Foo ...).

I want to make one final point: even though the first class things stored in WinFS are not elements and attributes, we are working on a really good XML storage story for WinFS. With the emphasis of Office on XML, it would just be plain stupid for us to do anything else. Oh, and I also think it is what our customers will want.

posted @ 10:41 PM | Feedback (1)

WinFS and Interfaces

Richard Tallent asks in addition to a type hierarchy, will there be inherent support for Interfaces instead of classes? This is a really interesting question and answering it gives me an opportunity talk about the third major type hierarchy in WinFS: extensions (the other two are items and relationships).

In CLR, interfaces are typically used to describe a behavioral contract. Since a class can implement multiple interfaces (but can be derived from only one class), interfaces allow for a kind of extensibility over time. An existing class can implement a new interface when adding new behavior allowing it to play a new role in a system.

WinFS schemas are primarily about describing data that will be stored, not behavior, so interfaces don't really fit into the WinFS data model. However, the API classes generated from the schema can implement behavior and can leverage interfaces just like any other CLR class.

But WinFS items do provide for an extensibility mechanism. In a schema I can defined an extension type with properties. Instances of extensions can be attached to item instances. For example, if I wanted to add an “hair color“ property to the standard Person item type I could define an extension as follows:

<ExtensionType Name=”PhysicalDescription” BaseType=”System.Storage.Extension”>
  <Property Name=“HairColor“ Type=“String“ Size=“50“/>
</ExtensionType>

I can add an instance of this extension to a Person item as follows:

ItemContext ic = ItemContext.Open();
Person p = Person.FindItemById( id );
PhysicalDescription d = new PhysicalDescription();
d.HairColor = “Brown”;
p.Extensions.Add( d );
ic.SaveChanges();

I can find all Person items representing people with brown hair using the code:

ItemContext ic = ItemContext.Open();
FindResult result = Person.FindAll(
  “Extensions.Case(PhysicalDescription).HairColor='Brown'“);

foreach( Person p in result ) {
  Console.WriteLine( p.DisplayName );
}

posted @ 9:52 PM | Feedback (3)