Tom's right on.

WinFS schemas aren't arbitrary XML. Schematized objects ("Items" in WinFS vocab) are defined according to the base types that the WinFS Data Model determines. The data model is the thing that defines what core behaviors all WinFS data has, how sync and rules come into play, what programmatic APIs are allowed, and also defines Relationships, Extensions and Nested Types. The data model also provides the specification of lifetime management and (to a certain extent) some shell interoperability functionality.

File-backed Items (FBIs) are what you think of as media files that WinFS "just adds metadata" to. However, there is huge value in defining a Longhorn application to run against WinFS Items directly for persistent storage. These Items are strongly typed, have discoverable schema, easy participation in rules, sync, full-text indexing, and can be defined with first class relationships (as opposed to properties promoted from a FBI that can be used in a join).

The decision to build WinFS on top of NTFS instead of replacing it directly is really complex and mostly irrelevant in the details with respect to everday users and ISVs.