Do I need SAX for .NET? (or does straight Java ports to C# make sense?)
After reading Oleg's post
about an upcoming SAX.NET implementation, and while I still
look forward to the other XML fellow developer working on that, I got certainly
excited and run to download and have a look at it. I was dissapointed, I must
say.
When I see a project implementing a class called XmlNamespaces containing
methods such as AddMapping, GetPrefixMapping, PushScope
and PopScope (among others), which do exactly the same as the
System.Xml.XmlNamespaceManager with its AddNamespace, LookupNamespace,
LookupPrefix, PushScope and PopScope, I
start wondering whether straight ports of other platform libraries really does
make sense in .NET. The mismatch doesn't end there:
-
There's IAttributes AND IAttributes2, and the corresponding implementations
called AttributesImpl and AttributesImpl2 (?!?!). Multiply that by ILocator,
IEntityResolver and so on. This is the first port and there's already interface
versioning problems?
-
There's an IXMLReader (note the casing) class with an EntityResolver property
which doesn't try to take advantage of .NET XmlResolver class, instead
reinventing it through the IEntityResolver interface
-
All the GetFeature/SetFeature/IProperty baggage that only makes sense when
multiple XML parsers are available and with varying features support (which
judging from the
silence of death
to my request for support to such scenarios isn't going to happen at all in
.NET)
-
Non-standard delegate such as
OnPropertyChange(IProperty property, object
newValue) - in .NET world it would have been OnPropertyChange(object
sender, ProperyChangeEventArgs e).
-
Trivial things such as:
<![CDATA[public static string GetString(RsId id)
{
string name = Enum.GetName(typeof(RsId), id);
return rm.GetString(name);
// Should have been:
// return rm.GetString(id.ToString());
}]]>
I think copying Java projects over to .NET is not always a good idea, specially
if done by people who doesn't work with C# and .NET on a daily basis. Examples of well done ports are NUnit and Log4Net, for example. Note,
however, that it wasn't until v2 that NUnit started using .NET-isms as custom
Attributes.
So, do I want SAX.NET? Definitely NOT. I like some of its ideas. We, as .NET
developers, should take the best ideas from it, mix them with .NET-friendly
APIs, take advantage of built-in infrastructure, and improve on it. So, I still
like it much more the Xml
Streaming Events (XSE) idea than any of these ports. I have to work
further on it, develop more use cases, clarify the API and give a second though
to some concepts, but it definitely integrates far better with current and
future .NET XML support. What I definitely don't want, is to code against
a pseudo-.NET/pseudo-Java API.
