SVG DOM

[Adam Badura]

I want to implement classes for SVG DOM as described in SVG
Specification. However I don't want to reimplement entire XML DOM because
firstly it is a lot of work and secondly this would make using them with
existing code harder (when compared to using System.Xml classes). I
preferred System.Xml.Linq classes since I do not require strict conformance
to DOM specification and I think X* classes are much easier to use. However
it seems that those classes were not meant to be inherited from. So what are
the options? What do you think I should do?

Adam Badura

[Martin Honnen]

Can you explain why you think that those "classes were not meant to be
inherited from"?
XElement
http://msdn.microsoft.com/en-us/library/system.xml.linq.xelement.aspx
for instance is certainly not sealed/final.

--

Martin Honnen --- MVP XML
http://msmvps.com/blogs/martin_honnen/

[Adam Badura]

Maybe I misread some part of the documentation or don't know C# well
enough but some functions and properties don't seem to be overridable. For
example XElement.Add
(http://msdn.microsoft.com/en-us/library/bb354061.aspx). Also for example
XDocument.Load is static rather then virtual so to construct my own classes
during loading XML I would have to provide in XMyDocument a function MyLoad
for example.
Or are there any examples of inheriting from X* classes?

Adam Badura

"Martin Honnen" <maho...@yahoo.de> wrote in message
news:ezUYzGCQ...@TK2MSFTNGP06.phx.gbl...

[Martin Honnen]

Adam Badura wrote:
> Maybe I misread some part of the documentation or don't know C# well
> enough but some functions and properties don't seem to be overridable.
> For example XElement.Add
> (http://msdn.microsoft.com/en-us/library/bb354061.aspx). Also for
> example XDocument.Load is static rather then virtual so to construct my
> own classes during loading XML I would have to provide in XMyDocument a
> function MyLoad for example.
> Or are there any examples of inheriting from X* classes?

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

[Adam Badura]

> 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.
All fine but what if the user copies XElement? The annotation is not
copied. (And even if I would find a way to copy it it would still be
incorrect as internal XElement reference would be to the original XElement.)
Also if user adds a new XElement to the tree I have very poor means to
detect it to be able to add appropriate annotation.
Do you have any suggestions to work around this?

Adam Badura

[Adam Badura]

>> 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