Dependency Properties or Attached Properties

Silverlight lets you create a property in an object (such as a rectangle) that derives from an ancestor element (such as a canvas). That is why we can write

<Rectangle Canvas.Top="10" />

Canvas.Top is a property of the Canvas, the ancestor element in the object tree.  Tim Heuer, one of the smarter folks I know, calls this a Dependency Property. I call this an attached Property. So I did a little spelunking to find out which is right, and here's what I found.  

“Attached properties” are defined in this Quick Start as follows:

 Getting or Setting Attached Properties
An attached property is a XAML language concept whereby elements can be assigned attributes for a property, even though that property is not present in the members list of the code type that backs the element.   

Ahhhh, the sweet taste of vindication. I should have stopped there, but then I found this blog (admittedly about WPF, but I think it applies), which shows Attached Properties as a subset of Dependency Properties:  

Dependency properties are used when the resolution of a property’s value is based on other properties or runtime settings (such as operating system settings).  Here are some important features of dependency properties: 

• Value resolution – DPs are used to form a system which can determine the actual property value based on various runtime information.  The resolution process has an order of precedence it assigns to various environmental contexts in which the property might exist.  For example, if the DP is being modified by an animation then the value supplied by the animation is the resolved value, but if it is not animated, then the value is derived from elsewhere.
• Self-contained validation – DPs can have custom callback methods execute when the property value has changed.  These callbacks can validate the new value or coerce the new property value into something acceptable, according to the semantics of the property.
• Default values – DPs provide a consistent mechanism for associating a default value with a property.  A DP’s default value has the lowest precedence in the value resolution process, meaning that if there is no other way to determine the property value, then the default value will be used.
• Property meta-data – The property system knows how a DP should behave based on meta-data supplied at the time the property is registered with the system.  Subclasses can tweak a DP by overriding the property’s meta-data, instead of completely re-implementing the property itself.  It is interesting to note that this meta-data is not stored in attributes, partly because the performance impact associated with using reflection to manipulate the meta-data was unacceptable.
• XAML friendly – Just like normal properties, DPs can be set in XAML.
• Value inheritance – Any DP can be given the ability to inherit its value from the property setting on an ancestor element, in the logical tree.  This provides similar functionality to the ambient properties used in Windows Forms.  Value inheritance is useful in many situations, such as propagating a data source down the element tree, font settings, flow direction (right-to-left) settings, etc.
• Attached properties – A form of dependency property which allows a child element to store a value associated with a property defined on an ancestor element. 

 My conclusion, after all of 10 minutes of research….  When you write:
                <Rectangle Canvas.Top=”15”> 

It is correct to call it  either an Attached property or a Dependency Property, in the sense that if All Throgs are Thrains and this is a Throg then it is also a Thrain.