Oh I'm not missing the point at all and I'm not saying its easy; but the problem is already solved with AD, to an extent. You can extend AD by adding attributes to existing classes, or add new classes; but the basic objects remain the same. You could even enforce
a vendor naming convention for new attributes or classes in much the same way we have -moz in CSS.
That way you avoid (1) because vendors can extend the base classes to add their own functionality. You don't avoid (2) of course; but that can be brought under control by having the OS define the base classes; and open up the base class design to a community
in much the same way the W3C is for HTML. But yes you can't stop (3) happening, unless you have conventions in place, in much the same way as meta directories do with LDAP and LDAP extensions, or how AD extensions work.
blowdart, you're sort-of right. However there's a huge difference between the AD and WinFS.
The AD is centrally deployed and managed and where the only applications allowed to modify the AD schema are those that are deployed by the system administrators, who have presumably tested and ensured that all applications deployed interoperate fully.
WinFS was going to be deployed on desktop computers and any application installed by the end-user would presumably be allowed to modify the schema. The end-user would have essentially no ability to verify the interoperability between applications. And the
vendors wouldn't necessarily either - there are a LOT of applications out there.
At the core, you're right: This could be solved with an extensible schema. But IMHO it would turn into a freaking nightmare for the customers. You know how some geeks hate the registry? Let me tell you, every failing the registry has (and I don't
think there are tat many of them, to be honest) would have been several orders of magnitude worse in WinFS. Geeks would absolutely