  2. Calling `serializer.save()` would then save the object instance to the database.
  
  This style is in line with how the `ModelForm` class works in Django, but is problematic for a number of reasons:
  
  * Some data, such as many-to-many relationships, cannot be added to the object instance until after it has been saved. This type of data needed to be hidden in some undocumentated state on the object instance, or kept as state on the serializer instance so that it could be used when `.save()` is called.
  * Instantiating model instances directly means that you cannot use model manager classes for instance creation, eg `ExampleModel.objects.create(...)`. Manager classes are an excellent layer at which to enforce business logic and application-level data constraints.
  * The two step process makes it unclear where to put deserialization logic. For example, should extra attributes such as the current user get added to the instance during object creation or during object save?
  
  We now use single-step object creation, like so:
  
 
</s> remove This gives us better seperation of concerns, allows us to use single-step
 </s> add This gives us better separation of concerns, allows us to use single-step </s> remove The `.restore_object()` method is now replaced with two seperate methods, `.create()` and `.update()`.
 </s> add The `.restore_object()` method is now replaced with two separate methods, `.create()` and `.update()`. </s> remove This change also means that we no longer use the `.full_clean()` method on model instances, but instead perform all validation explicitly on the serializer. This gives a cleaner seperation, and ensures that there's no automatic validation behavior on `ModelSerializer` classes that can't also be easily replicated on regular `Serializer` classes.
 </s> add This change also means that we no longer use the `.full_clean()` method on model instances, but instead perform all validation explicitly on the serializer. This gives a cleaner separation, and ensures that there's no automatic validation behavior on `ModelSerializer` classes that can't also be easily replicated on regular `Serializer` classes. </s> remove * `.data` - Returns the outgoing primative representation.
 </s> add * `.data` - Returns the outgoing primitive representation. </s> remove * There can be complex dependancies involved in order of saving multiple related model instances.
 </s> add * There can be complex dependencies involved in order of saving multiple related model instances.
* Some data, such as many-to-many relationships, cannot be added to the object instance until after it has been saved. This type of data needed to be hidden in some undocumented state on the object instance, or kept as state on the serializer instance so that it could be used when `.save()` is called.
  2. Calling `serializer.save()` would then save the object instance to the database.
  
  This style is in line with how the `ModelForm` class works in Django, but is problematic for a number of reasons:
  
* Some data, such as many-to-many relationships, cannot be added to the object instance until after it has been saved. This type of data needed to be hidden in some undocumented state on the object instance, or kept as state on the serializer instance so that it could be used when `.save()` is called.
  * Instantiating model instances directly means that you cannot use model manager classes for instance creation, eg `ExampleModel.objects.create(...)`. Manager classes are an excellent layer at which to enforce business logic and application-level data constraints.
  * The two step process makes it unclear where to put deserialization logic. For example, should extra attributes such as the current user get added to the instance during object creation or during object save?
  
  We now use single-step object creation, like so:
  
keep keep keep keep replace keep keep keep keep keep
 Minor: fix spelling and grammar, mostly in 3.0 announcement 
docs/topics/3.0-announcement.md