>> It seems the intended way to reuse LINQ to XML classes is the annotation 
>> feature:
>> http://blogs.msdn.com/mikechampion/archive/2006/08/17/705278.aspx
>
>    This seems fine enough. And possibility to "inject methods" through 
> extensions seems very helpful as well (an example shown in 
> http://blogs.msdn.com/mikechampion/archive/2006/09/10/748408.aspx).
>    However after few small code experiments I came to a conclusion that it 
> might not be enough. I considered adding classes with SVG DOM-like 
> properties as annotations to the XElements. An example is the base IDL 
> SVGElement which contains attributes "id" and "xmlbase" (referring to "id" 
> element attribute and "xml:base" element attribute). I changed it to an 
> SvgElement class with Id and XmlBase properties. But then natural question 
> occurs: should those be get only or get/set? In the IDL's SVGElement they 
> are get/set (with some restrictions).  If I was to support the setting how 
> would I do that? I considered constructing my SvgElement with XElement (to 
> which it referrers) given during construction and not only reading 
> appropriate data but also storing the XElement to be able latter to set 
> the data in setters.

    There is yet another solution. Instead of adding annotation data I could 
use extension methods. To continue the example I could make GetId and SetId 
extension methods for XElement. This could be generalized to other functions 
and attributes defined in SVG DOM. (Functions and attributes for more 
specific SVG elements could just check at the beginning whether the "this" 
XElement is the required one.)
    However again there are some drawbacks. First attributes no longer can 
be mapped to properties as there are no "extension properties" (pity, as I 
like properties very much). I have to have Set* and Get* methods. But this 
is a minor issue. A more important one is that the values returned by 
functions will have to be computed each time anew since the extension 
methods do not have any "memory". I might want to make some kind of cache in 
the class defining the extension method this however seems quite complex (to 
update the cache upon value change) and will be hard to control (so that the 
cache does not grow to large storing xml trees already unused).
    So after all I think that DOM-like extending System.Xml.Linq classes is 
kind of hard if at all possible.

    Adam Badura