Talk:WinFS

Removed from the article

This is a list of all the portions removed from the article. All wiki formatting has been disabled using nowiki.

I removed these because they do not appear in the reference cited:

• Under Architecture: At the bottom of the WinFS stack lies ''WinFS Core'', which interacts with the filesystem and provides file-access and -addressing capabilities.<ref name="grimaldi" /> The relational engine leverages the WinFS core services to present a structured store and other services such as locking, which the WinFS runtime uses to implement the functionality. The WinFS runtime exposes ''services'' such as ''Synchronization'' and ''Rules'' that can be used to synchronize WinFS stores or perform certain actions on the occurrence of certain events.<ref name="grimaldi" />

I removed these because they discuss the Windows Longhorn implementation of WinFS, instead of the WinFS Beta 1 for Windows XP SP2. They may be restored someday.

• Under Data store: A data unit that has to be stored in a WinFS store is called a WinFS ''Item''.<ref name="wildermuth" /><ref name="grimes" /> A WinFS item, along with the core data item, also contains information on how the data item is related to other data. This ''Relationship'' is stored in terms of logical links. Links specify which other data items the current item is related with. Put in other words, links specify the relationship of the data with other data items. Links are physically stored using a link identifier, which specifies the name and intent of the relationship, such as ''type of'' or ''consists of''.<ref name="wildermuth" /> The link identifier is stored as an attribute of the data item. All the objects that have the same link ID are considered to be related.<ref name="wildermuth" /> An XML schema, defining the structure of the data items that will be stored in WinFS, must be supplied to the WinFS runtime beforehand.<ref name="wildermuth" />
• Under Type system: ====Type system==== [[Image:WinFS1.svg|thumb|WinFS Type Hierarchy]] The most important difference between a file system and WinFS is that WinFS knows the type of each data item that it stores. And the type specifies the properties of the data item. The WinFS type system is closely associated with the .NET framework's concept of classes and inheritance. A new type can be created by extending and nesting any predefined types.<ref name="wildermuth" /> WinFS provides four predefined base types – ''Items'', ''Relationships'', ''ScalarTypes'' and ''NestedTypes''.<ref name="wildermuth" /> An Item is the fundamental data object which can be stored, and a Relationship is the relation or link between two data items. Since all WinFS items must have a type, the type of item stored defines its properties. The properties of an Item may be a ScalarType, which defines the smallest unit of information a property can have, or a NestedType, which is a collection of more than one ScalarTypes and/or NestedTypes. All WinFS types are made available as .NET CLR classes.<ref name="grimes" /> Any object represented as a data unit, such as contact, image, video, document etc., can be stored in a WinFS store as a specialization of the Item type.<ref name="grimes" /> By default, WinFS provides Item types for Files, Contact, Documents, Pictures, Audio, Video, Calendar, and Messages. The File Item can store any generic data, which is stored in file systems as files. But unless an advanced schema is provided for the file, by defining it to be a specialized Item, WinFS will not be able to access its data. Such a file Item can only support being related to other Items.<ref name="wildermuth" /> [[Image:WinFS2.svg|thumb|Defining a new Type]] A developer can extend any of these types, or the base type Item, to provide a type for his custom data. The data contained in an Item is defined in terms of properties, or fields that hold the actual data. For example, an Item ''Contact'' may have a field ''Name'' that is a ScalarType, and one field ''Address'', a NestedType, which is further composed of two ScalarTypes. To define this type, the base class Item is extended and the necessary fields are added to the class.<ref name="wildermuth" /> A NestedType field can be defined as another class that contains the two ScalarType fields. Once the type is defined, a schema has to be defined, which denotes the primitive type of each field, for example, the Name field is a String, the Address field is a custom defined Address class, both the fields of which are Strings. Other primitive types that WinFS supports are Integer, Byte, Decimal]], Float, Double, Boolean and DateTime, among others.<ref name="wildermuth" /> The schema will also define which fields are mandatory and which are optional.<ref name="wildermuth2">{{cite web | url = http://msdn2.microsoft.com/en-us/library/ms996631.aspx | title = A Developer's Perspective on WinFS: Part 2 |date=July 2004 | accessdate = 2007-06-30 | author = Shawn Wildermuth | work = MSDN | publisher = Microsoft }}</ref> The Contact Item defined in this way will be used to store information regarding the Contact, by populating the properties field and storing it. Only those fields marked as mandatory needs to be filled up during initial save.<ref name="grimes" /> Other fields may be populated later by the user, or not populated at all. If more properties fields, such as ''last conversed date'', need to be added, this type can be extended to accommodate them. Item types for other data can be defined similarly. [[Image:WinFS3.svg|thumb|Relationships]] WinFS creates tables for all defined Items.<ref name="wildermuth2" /> All the fields defined for the Item form the columns of the table and all instances of the Item are stored as rows in the table for the respective Items. Whenever some field in the table refers to data in some other table, it is considered a relationship. The schema of the relationship specifies which tables are involved and what the kind and name of the relationship is. The WinFS runtime manages the relationship schemas.<ref name="grimes" /> All Items are exposed as .NET CLR objects, with a uniform interface providing access to the data stored in the fields. Thus any application can retrieve object of any Item type and can use the data in the object, without being aware of the physical structure the data was stored in.<ref name="wildermuth" /> WinFS types are exposed as .NET classes, which can be instantiated as .NET objects. Data are stored in these type instances by setting their properties. Once done, they are persisted into the WinFS store. A WinFS store is accessed using an ''ItemContext'' class (see [[#Data retrieval|Data retrieval]] section for details). ItemContext allows transactional access to the WinFS store; i.e. all the operations since binding an ItemContext object to a store till it is closed either all succeed or are all rolled back. As changes are made to the data, they are not written to the disc; rather they are written to an in-memory log. Only when the connection is closed are the changes written to the disc in a batch. This helps to optimize disc I/O.<ref name="DotNetShow" /> The following code snippet, written in C#, creates a contact and stores it in a WinFS store. <syntaxhighlight lang="csharp"> //Connect to the default WinFS store using(ItemContext ic = ItemContext.Open()) { //Create the contact and set the data in appropriate properties ContactEAddress contact = new ContactEAddress() { Name = new PersonName() { // Name is a ComplexType Displayname = "Doe, John", FirstName = "John", LastName = "Doe" }, TelephoneNumber = new TelephoneNumber() { // Telephone number is a ComplexType Country = CountryCode.Antarctica, Areacode = 4567, Number = 9876543210 }, Age = 111 // Age is a SimpleType }; //Add the object to the user's personal folder. //This relates the item with the Folder pseudo-type, for backward //compatibility, as this lets the item to be accessed in a folder //hierarchy for apps which are not WinFS native. Folder containingFolder = UserDataFolder.FindMyPersonalFolder(); containingFolder.OutFolderMemberRelationship.AddItem(ic, contact); //Find a document and relate with the document. Searching begins by creating an //ItemSearcher object. Each WinFS type object contains a GetSearcher() method //that generates an ItemSearcher object which searches documents of that type. using (ItemSearcher searcher = Document.GetSearcher(ic)) { Document d = searcher.Find(@"Title = 'Some Particular Document'"); d.OutAuthoringRelationship.AddItem(ic, contact); } //Since only one document is to be found, the ItemContext.FindOne() method //could be used as well. //Find a picture and relate with it using (ItemSearcher searcher = Picture.GetSearcher(ic)) { Picture p = searcher.Find(@"Occasion = 'Graduation' and Sequence = '3'"); p.OutSubjectRelationship.AddItem(ic, contact); } //Persist to the store and close the reference to the store ic.Update(); } </syntaxhighlight> ====Relationships==== A datum can be [[Relational model|related]] to one more item, giving rise to a one-to-one relationship, or with more than one items, resulting in a one-to-many relationship.<ref name="wildermuth" /> The related items, in turn, may be related to other data items as well, resulting in a network of relationships, which is called a many-to-many relationship. Creating a relationship between two Items creates another field in the data of the Items concerned which refer the row in the other Item's table where the related object is stored.<ref name="grimes" /> [[Image:WinFS4.svg|thumb|WinFS Relationships]] In WinFS, a Relationship is an instance of the base type Relationship, which is extended to signify a specialization of a relation. A Relationship is a mapping between two items, a Source and a Target. The source has an Outgoing Relationship, whereas the target gets an Incoming Relationship.<ref name="wildermuth2" /> WinFS provides three types of primitive relationships – ''Holding Relationship'', ''Reference Relationship'' and ''Embedding Relationship''.<ref name="wildermuth" /> Any custom relationship between two data types are instances of these relationship types. *'''Holding Relationships''' specifies ownership and lifetime (which defines how long the relationship is valid) of the Target Item. For example, the Relationship between a folder and a file, and between an Employee and his Salary record, is a Holding Relationship – the latter is to be removed when the former is removed. A Target Item can be a part of more than one Holding Relationships. In such a case, it is to be removed when all the Source Items are removed. *'''Reference Relationships''' provide linkage between two Items, but do not have any lifetime associated, i.e., each Item will continue to be stored even without the other. *'''Embedding Relationships''' give order to the two Items that are linked by the Relationship, such as the Relationship between a Parent Item and a Child Item. Relationships between two Items can either be set programmatically by the application creating the data, or the user can use the WinFS Item Browser to manually relate the Items.<ref name="wildermuth2" /> A WinFS item browser can also graphically display the items and how they are related, to enable the user to know how their data are organized.<ref name="grimes" /> ===RAV=== WinFS supports creating ''Rich Application Views'' (RAV) by aggregating different data in a virtual table format. Unlike [[View (database)|database view]], where each individual element can only be a scalar value, RAVs can have complex Items or even collections of Items. The actual data can be across multiple data types or instances and can even be retrieved by traversing relationships.<ref name="DotNetShow" /> RAVs are intrinsically paged (dividing the entire set of data into smaller ''pages'' containing disconnected subsets of the data) by the WinFS runtime. The page size is defined during creation of the view and the WinFS API exposes methods to iterate over the pages. RAVs also supports modification of the view according to different grouping parameters. Views can also be queried against.

- Emir214 (talk) 02:19, 24 March 2021 (GMT)

I also removed this portion, because the first paragraph is Longhorn implementation, and the second paragraph is not in the source cited: WinFS models data using the data items, along with their relationships, extensions and rules governing its usage.<ref name="grimaldi" /> WinFS needs to understand the type and structure of the data items, so that the information stored in the data item can be made available to any application that requests it. This is done by the use of schemas. For every type of data item that is to be stored in WinFS, a corresponding schema needs to be provided to define the type, structure and associations of the data. These schemas are defined using XML.<ref name="wildermuth" /> Predefined WinFS schemas include schemas for documents, e-mail, appointments, tasks, media, audio, video, and also includes system schemas that include configuration, programs, and other system-related data.<ref name="grimaldi" /> Custom schemas can be defined on a per-application basis, in situations where an application wants to store its data in WinFS, but not share the structure of that data with other applications, or they can be made available across the system.<ref name="grimaldi" />

- Emir214 (talk) 03:01, 24 March 2021 (GMT)

Removed 28 March 2021

Removed all references to the .NET show, 1) because they all refer to "Longhorn" era implementation, and 2) I can't download the file in full. A link is available in the Wiki code. Removed from Organize: Data stored and managed by the system are instances of the data type recognized by the WinFS runtime. The data are structured by means of properties. For example, an instance of a ''résumé'' type will surface the data by exposing properties, such as ''Name'', ''Educational Qualification'', ''Experience''. Each property may be a simple type (''strings'', ''integers'', ''dates'') or complex types (''contacts'').<ref name="DotNetShow">{{cite web | url = http://download.microsoft.com/download/6/b/6/6b659b87-eafa-4c15-8783-1476e59bba13/dotnetshow41_300k.EXE | title = WinFS on The .NET Show | archiveurl = https://web.archive.org/web/20141205131610/http://download.microsoft.com/download/6/b/6/6b659b87-eafa-4c15-8783-1476e59bba13/dotnetshow41_300k.EXE | archivedate = 5 December 2014 | accessdate = 17 March 2021}}</ref> Different data types expose different properties. Besides that, WinFS also allows different data instances to be related together. Relationships are also exposed as properties; for example if a document is related to a contact by a ''Created By'' relationship, then the document will have a ''Created By'' property. When it is accessed, the relationship is traversed and the related data returned.<ref name="DotNetShow" /> By following the relations, all related data can be reached.

From Data retrieval: [[Image:WinFSFlowChart.svg|thumb|Flowchart for creating, searching and updating WinFS data instances]] The primary mode of data retrieval from a WinFS store is querying the WinFS store according to some criteria,<ref name="grimaldi" /> which returns an enumerable set of items matching the criteria. The criteria for the query is specified using the OPath query language. The returned data are made available as instances of the type schemas, conforming to the .NET object model.<ref>{{cite web | url = http://blogs.msdn.com/winfs/archive/2005/11/18/494707.aspx | title = Unify, Organize, Explore, and Innovate. Oh my! (Part 4) | author = Vijay Bangaru | publisher = WinFS Team Blog | accessdate = 2007-06-30 | archiveurl = https://web.archive.org/web/20070618154258/http://blogs.msdn.com/winfs/archive/2005/11/18/494707.aspx | archivedate = 2007-06-18}}</ref> The data in them can be accessed by accessing the properties of individual objects.<ref name="wildermuth2" /> Relations are also exposed as properties. Each WinFS Item has two properties, named ''IncomingRelationships'' and ''OutgoingRelationships'', which provide access to the set of relationship instances the item participates in. The other item which participates in one relationship instance can be reached through the proper relationship instance.<ref name="DotNetShow" /><ref name="wildermuth2" /> The fact that the data can be accessed using its description, rather than location, can be used to provide end-user organizational capabilities without limiting to the hierarchical organization as used in file-systems. In a file system, each file or folder is contained in only one folder. But WinFS Items can participate in any number of holding relationships, that too with any other items. As such, end users are not limited to only file/folder organization. Rather, a contact can become a container for documents; a picture a container for contacts and so on. For legacy compatibility, WinFS includes a pseudo-type called ''Folder,'' which is present only to participate in holding relationships and emulate file/folder organization. Since any WinFS Item can be related with more than one Folder item, from an end user perspective, an item can reside in multiple folders without duplicating the actual data.<ref name="DotNetShow" /> Applications can also analyze the relationship graphs to present various filters. For example, an email application can analyze the related contacts and the relationships of the contacts with restaurant bills and dynamically generate filters like ''"Emails sent to people I had lunch with"''.

From Searches: The WinFS API provides a class called the ''ItemContext'' class, which is bound to a WinFS store. The ''ItemContext'' object can be used to scope the search to the entire store or a subset of it. It also provides transactional access to the store.<ref name="ForDev" /> An object of this class can then spawn an ''ItemSearcher'' object which then takes the type (an object representing the type) of the item to be retrieved or the relationship and the OPath query string representing the criteria for the search.<ref name="wildermuth2" /><ref name="OPath">{{cite web | url = http://msdn2.microsoft.com/en-us/library/aa480689.aspx | title = An Introduction to "WinFS" OPath | date = October 18, 2004 | accessdate = 2007-06-30 | author = Thomas Rizzo, Sean Grimaldi | work = MSDN | publisher = Microsoft }}</ref> A set of all matches is returned, which can then be bound to a UI widget for displaying ''en masse'' or enumerating individually.<ref name="grimes" /> The properties items can also be modified and then stored back to the data store to update the data. The ItemContext object is ''closed'' (which marks the end of association of the object with the store) when the queries are made or changes merged into the store. Related items can also be accessed through the items. The ''IncomingRelationships'' and ''OutgoingRelationships'' properties give access to all the set of relationship instances, typed to the name of the relationship. These relationship objects expose the other item via a property. So, for example, if a picture is related to a picture, it can be accessed by ''traversing'' the relationship as: <syntaxhighlight lang="csharp"> ContactsCollection contacts = picture.OutgoingRelationships.Cast(typeof(Contact)).Value; //This retrieves the collection of all outgoing relationships from a picture object //and filters down the contacts reachable from them and retrieves its value. //Or the relationship can be statically specified as ContactsCollection contacts = picture.OutgoingRelationships.OutContactRelationship.Contact; </syntaxhighlight> {{anchor|OPath}} An OPath query string allows to express the parameters that will be queried for to be specified using ''Item'' properties, embedded ''Items'' as well as ''Relationships''.{{citation needed|date=January 2015}} It can specify a single search condition, such as ''"title = Something'"'', or a compound condition such as ''"title = 'Title 1' || title = 'Title 2' && author = 'Someone'"''. These boolean and relational operations can be specified using C# like ''&&'', ''||'', ''='', ''!='' operators as well as their English-like equivalent like ''EQUAL'', ''NOT EQUAL''. SQL like operators such as ''LIKE'', ''GROUP BY'' and ''ORDER BY'' are also supported, as are wildcard conditions.{{citation needed|date=January 2015}} So, ''"title LIKE 'any*'"'' is a valid query string. These operators can be used to execute complex searches such as <syntaxhighlight lang="csharp"> using (ItemContext ic = ItemContext.Open() ) { //Searching begins by creating a ItemSearcher object. The searcher is created from a //relationship instance because the contacts being searched for are in relation. The //first parameter defines the scope of the search. An ItemContext as the scope means //the entire store is to be searched. Scope can be limited to a set of Items which may //be in a holding relationship with the contacts. In that case, the set is passed as //the scope of the search. ItemSearcher searcher = OutContactRelationship.GetTargetSearcher(ic, typeof(Contact)); ContactCollection contacts = searcher.FindAll("OutContactRelationship.Contact.Name LIKE 'A*'"); } </syntaxhighlight> The above code snippet creates an ItemSearcher object that searches on the ''OutContactRelationship'' instance that relates pictures and contacts, in effect searching all pictures related with a contact. It then runs the query ''Name LIKE 'A*'"'' on all contacts reachable through ''OutContactRelationship'', returning the list of ''"contacts whose names start with A and whose pictures I have"''. Similarly, more relationships could be taken into account to further narrow down the results.<ref name="DotNetShow" /><ref name="wildermuth2" /> Further, a natural language query processor, which parses query in natural language and creates a well-formed OPath query string to search via proper relationships, can allow users to make searches such as ''"find the name of the wine I had with person X last month"'', provided financial management applications are using WinFS to store bills. Different relations specify a different set of data. So when a search is made that encompasses multiple relations, the different sets of data are retrieved individually and a union of the different sets is computed. The resulting set contains only those data items that correspond to all the relations.<ref name="wildermuth2" />

From Notifications: WinFS also includes better support for handling data that changes frequently. Using WinFS ''Notifications'', applications choose to be notified of changes to selected data ''Items''. WinFS will raise an ''ItemChangedEvent'', using the .NET Event model, when a subscribed-to Item changes, and the event will be published to the applications.<ref name="wildermuth2" />

- Emir214 (talk) 04:24, 28 March 2021 (BST)

Also removed from Data sharing, because (1) the portions attributed to Padgett's article do not appear in the source cited and (2) the citation to Thurrott was already repetitive. I already moved the Shell namespace portion from Applications to Data sharing: WinFS allows easy sharing of data between applications, and among multiple WinFS stores, which may reside on different computers, by copying to and from them.<ref name="Sync">{{cite web | url = http://blogs.msdn.com/winfs/archive/2005/11/17/494222.aspx | title = Getting Data Into WinFS with WinFS Synchronization | author = Neil Padgett | publisher = WinFS Team Blog | accessdate = 2007-06-30 | archiveurl = https://web.archive.org/web/20070217152210/http://blogs.msdn.com/winfs/archive/2005/11/17/494222.aspx | archivedate = 2007-02-17}}</ref> A WinFS item can also be copied to a non-WinFS file system, but unless that data item is put back into the WinFS store, it will not support the advanced services provided by WinFS. The WinFS API also provides some support for sharing with non-WinFS applications. WinFS exposes a shell object to access WinFS stores. This object maps WinFS items to a virtual folder hierarchy, and can be accessed by any application.<ref name="PaulT" /> WinFS data can also be manually shared using network shares, by sharing the legacy shell object.<ref name="Sync" /> Non-WinFS file formats can be stored in WinFS stores, using the File Item, provided by WinFS. Importers can be written, to convert specific file formats to WinFS Item types.<ref name="Sync" /> In addition, WinFS provides services to automatically synchronize items in two or more WinFS stores, subject to some predefined condition, such as "''share only photos''" or "''share photos that have an associated contact X''".<ref name="Sync" /> The stores may be on different computers. Synchronization is done in a peer-to-peer fashion; there is no central authority. A synchronization can be either manual or automatic or scheduled. During synchronization, WinFS finds the new and modified Items, and updates accordingly. If two or more changes conflict, WinFS can either resort to automatic resolution based on predefined rules, or defer the synchronization for manual resolution. WinFS also updates the schemas, if required.<ref name="Sync" />