I never looked too deeply into how WinFS was implemented, but one thing I took away from it was that meta-data would be self-described in XML. I'm interested in being able to attach any information I want to any file, using some format like Adobe's XMP, and have it readable in Explorer on any Windows computer. That would benefit me as an end-user just because it would allow me to catalogue and annotate my files. If different programs wanted to share information, I'd guess they would simply have to agree to some defined standard.Larry Osterman said:Who gets to define the schema for a "contact"? How about a "document"?blowdart said:*snip*
Once you start thinking in those terms, you realize quite quickly that the idea of abstract "objects" can quickly become unworkable. That's because Outlook's idea of what belongs in a contact object might be very different from Windows Mail's idea, which might be very different from Thunderbird's idea.
Here's a really simple example: To Outlook, an email address is a multivalued string property which lists all the possible email addresses for a particular recipient (there could be a dozen or so of them depending on the topology of your network). To Windows Mail, an email address would be just an SMPT address. To the email system I wrote back in high school, it's a RSTS-E account name ([<octal value>,<octal value>], to something else, it might be something totally different, with a totally different syntax.
Now consider what happens when you use a contact in Outlook that was created by my high school email program?. Outlook doesn't know how to send email to this contact, it doesn't even know how to interpret the address.
Can you guarantee that all clients of this object store all handle these cases properly?
This is just one small example of the kinds of interoperability problems you can get - this one is probably solvable, but there are others that aren't.