Scott Hanselman

I referred to MbUnit once as "abandonware" only to be corrected (rightly so) by Andy Stopford (here's a listserv about the issue). In this case, it was not clear at a cursory glance if it was being "actively developed."  Here's some metrics that were provided by Jay Flowers that prove that MbUnit is very alive:

Google Groups:
MbUnit.Dev - 62 Members with 60 posts last month
MbUnit.User - 120 Members with 35 posts last month

8 Dev Leaders with rights to Subversion

Here is the Svn FishEye:
http://www.mertner.com/fisheye/browse/MbUnit

4 Devs committing changes in Aug
264 files changes/28 revisions in Aug

Other folks have done the same thing to DasBlog that I did to MbUnit. Take a cursory glance at the DasBlog SF.NET Projects Page a few weeks back and you'd fine many unanswered questions. In both instances - DasBlog and MbUnit - the project owners needed to take into consideration the external perception by the community of the projects and tighten the screws a bit, all to avoid the label of "Abandonware."

Another word invented by Roy Osherove was "frozeablilty" (or chance of being frozen/abandoned. Perhaps frozeabilitishipfulness is a better word?:

MbUnit is also one of the topics that I continually have a dilemma about using. Since its not the de-facto standard out there, I always feel there's a chance of it being frozen in mid development, making all those who depend on it frozen along with it.

[Update: Andrew, one of the leads on mbUnit,  makes some good points on why he thinks this is far from happening - which is reassuring, and I'd like to hold out longer before making a final call on it's "frozeability".]

Now, we're picking on DasBlog and MbUnit here, but both actively developed projects that aren't abandoned. But let's talk about the real issue. Is software that has been abandoned bad? Is it un-usable? Should we only use software that is actively developed?

Abandonware Example - A .NET Implementation of Schematron

We recently needed to do some data import work, and we were using XML as the source format and XSD to describe the constraints of the validity of the data. Xml Schema isn't well suited for complex data with conditional interrelationships.

For example, if I have a Payment in Xml Schema, it might have a FromAccountID and an optional DateCompleted (and many other things):

 <xs:complexType name="Payment">
  <xs:sequence>
   <xs:element name="FromAccountID">
    <xs:simpleType>
     <xs:restriction base="xs:string">
      <xs:maxLength value="25"/>
      <xs:whiteSpace value="preserve"/>
     </xs:restriction>
    </xs:simpleType>
   </xs:element>
   <xs:element name="DateCompleted" minOccurs="0">
    <xs:simpleType>
     <xs:restriction base="xs:date"/>
    </xs:simpleType>
   </xs:element>
...

But, there's a business rule that indicates that if FromAccountID is "PAID" then there must be a DateCompleted. This kind of condition isn't expressable in XSD. I started looking for other solutions like RelaxNG or Schematron.

Schematron is an interesting spec, but the nutshell explanation is that you can augment XSD with additional assertions using XPath. You can also (with some implementations) include Schematron patterns inside of existing Xml Schemas using the xs:annotation element. Schematron the spec is being actively talked about (article at IBM from this July), commented on by Microsoft PMs (quote from July) but there's a reference implementation using XSLT but it hasn't been looked at since 2001. Some bloggers have commented on the uneven state of Schematron.

I can extend this XSD with Schematron like this:

 <xs:complexType name="Payment">
  <xs:annotation>
   <xs:appinfo>
    <pattern name="Payment Rules" xmlns="http://www.ascc.net/xml/schematron">
     <rule context="Payment">
      <assert test="(FromAccountID = 'PAID' and DateCompleted) or 
          (FromAccountID != 'PAID')">
             PAID Payments must have a Date Completed
      </assert>
     </rule>
    </pattern>
   </xs:appinfo>
  </xs:annotation>
...

And this simple example gives me the semantics I need and I get output like this from a console test application that are exactly what I need:

Results from Schematron validation
    From pattern "Payment Rules"
        Assert fails: PAID Payments must have a Date Completed
        At: /FI[1]/Relationship[1]/Payee[1]/Payment[2]
            <Payment>...</Payment>
            (Line: 73, Column: 5)

However, doubts about Schematron persist. Uche Ogbuji says:

"It has been a sketchy time for Schematron fans. Rick Jelliffe, the father of Schematron has had pressing matters that have prevented him from putting much work into Schematron for a while. Many questions still remain about the technology specification, and alas, there appears to be no place to keep discussions going on these and other matters (the mailing list on SourceForge appears to be defunct, with even the archives giving a 404. Here are some notes on recent Schematron developments I've come across."

However, it is moving towards being an ISO spec (or may already be?) and there's active talk going on at the SchematronLoveIn mailing list.

There's also a great (but oldish) article on Introducing the Schematron here. Looks like it might be a fine idea. The XSLT implementation worked group, but I also noticed a native C# .NET implementation at SourceForge. This implementation has the very much added benefit of giving me not only an event when a Schematron assertion fails, but also the line number and additional context. However, it's not been touched since 2002.

Is that a bad thing?

I asked the author of the .NET implementation of Schematron, Daniel Cazzulino, what he thought and he said:

"Mmm... schematron is mostly abandoned as the new compiled XSLT in .NET 2.0 makes the need for an "xpath native" implementation pretty much useless. If you use the reference meta-stylesheet and provide a nice .NET API over it (alongside better results reporting, such as an object model that can also be serialized into XML and/or XSLT'ed into HTML reports), you should be OK. And you would be in a better position feature-wise, as I never got to complete support for diagnostics elements, etc., which is readily implemented in the meta-stylesheet."

To translate Daniel's techno-speak into regular-guy-speak he's saying

"Ya, that sucks. You can write a wrapper around this other thing yourself, and that'd be a good idea in the long run, but ya, that sucks."

However, this project isn't using .NET 2.0 (client requirements) and the existing .NET Schematron stuff not only works, but it works great. It's many times faster than the XSLT implementation and did I mention, it's open source. That means, I have the source.

It's not like the Open Source Fairy is going to delete the software (and source) off my hard drive if a project disappears.

To quote Patrick Cauldwell, "Sure, we are assuming the burden of maintenance when we use it, but we're doing that anyway as there's no assurance that someone in the OS community would care about a bug we found."

This is exemplified by Stuart's recent spitting into the wind with a catastrophic but ignored Subversion case-sensitivity bug.

Moral: What you care about, often ain't what the other guy cares about.

Conclusion: The Schematron .NET implementation is total abandonware and I'm going to use it anyway. Since when did 3 year old software become abandoned. I haven't been in my backyard in 3 years, but if I catch you camping there I'll ask you to leave.

(If you'd like to receive ComputerZen.com via email, you can subscribe to this blog as a newsletter for free. Subscribe to Scott Hanselman - ComputerZen.com by Email)

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

About   Newsletter

Hosting By