Pluggable XML processing scenarios?

[Daniel Cazzulino [MVP]]

Hi guys, I'm thiking about the new XmlFactory class in Whidbey, and trying
to imagine usage scenarios and see if it fits them all. We've been
discussing publicly with Dare
(http://www.25hoursaday.com/weblog/CommentView.aspx?guid=51908783-d75d-4924-
ac37-c19f25dbac44) about this.

The scenario I'm thiking of is:
- An application is developed to comply to certain schema/s
- XmlFactory is configured wherever it's needed with those schemas and
all the other settings for validation, resolver, etc.
- Obviously this has to be repeated wherever we need it, unless we use
some static global factory instance for each setting we need (i.e. one
static factory for PO reading/validating, another for Customer docs, etc).

So far, this seems like the current usage expected for the XmlFactory.
Please correct me if I missed something.
Scenarios not included and (IMO) certainly possible:

1 - Refactoring schemas to achieve greater modularity/reusability, by
spliting it in several files: would require changes to the client (WRT the
factory) code and recompilation.
2 - The developer wishes to use a hardware-accelerated XML processor (i.e.
http://www.tarari.com/products-xml.html) or a faster/different
parser/validator (i.e. wrapper around MSXML, or ports of
Xerces -http://www.dotnetsource.org/xerces.net/index.html- or Saxon, or
newer ones): no way to plug into the factory itself. Code needs to be
changed to use the new classes and recompiled.
3 - Either case could only be used for custom code, but not for built-in
infrastructure. For example, the webservice support in ASP.NET would
continue to use the built-in implementations because there's no way to tell
the factory do otherwise.

There's the issue of whether these features should be supported by the API
itself, or left for the developer to figure out. Clearly, not supporting
them at the API level leads to point 3 above.
There's another scenario where similar requirements are more usual: ADO.NET.
There, you surely expect openness right from the start, and several third
party providers already exist. The problems above, are solved by
implementing the full Abstract Factory design pattern, and providing first
class API-level support for loading these factories dynamically. You can
configure these factories and give them a name:

<system.data>
<DbProviderFactories>
<add name="Odbc Data Provider"
invariant="System.Data.Odbc"
support="1BF"
description=".Net Framework Data Provider for Odbc"
type="System.Data.Odbc.OdbcFactory, System.Data,
Version=1.2.3400.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/>
...

Now, you can retrieve this specific factory by name:

DbProviderFactory factory =
DbProviderFactories.GetFactory("System.Data.Odbc");

Imagine that I can have a factory named "SAP" and let the config. tell who
is implementing the connection, commands, etc. This makes for full
extensibility, of course.
The problems with the current implementation of the XmlFactory is that it
doesn't allow for any configurability. If I had the following config for it:

<system.xml>
<XmlProviderFactories>
<add name="CustomerValidated"
invariant="MyCrm.Customer"
description="A factory for creating automatic
customer-validating readers"
type="MyCrm.CustomerValidatingFactory, MyCrm"/>
...

My code could simply use:

XmlFactory factory = XmlFactories.GetFactory("MyCrm.Customer");
XmlReader reader = factory.CreateReader();
// load it

At this point, I can refactor the schemas, change the way I load and cache
them, even switch validation language (i.e. move to RelaxNG or Schematron)
and the client code would remain untouched. All that work is performed
inside the factory itself. I can also change completely the XML processing
stack and plug-in the hardware accelerated card and corresponding API calls
without the client code even knowing it. Of course, I can also test the
various implementations only by changing the config, instead of recompiling
everything.

There should also be a default factory, which should point to the built-in
implementation much like today's XmlFactory. Of course, having this default
config in machine.config would make for easy use if the developer doesn't
need/want to use customized factories. The config would specify the default
as follows:

<system.xml>
<XmlProviderFactories default="System.Xml.XmlFactory">

This default factory should be fully extensible, meaning all methods should
be virtual, to allow extenders to override specific functionality. By having
the default factory configurable, I can effectively plug any compatible
implementation right inside the .NET Framework, and get the benefits I seek
from third-party XML processing products even for built in features such as
ASP.NET WebServices, which would automatically start using the new default
factory. Of course, this means the internal APIs can't simply assume I will
always use the .NET implementations. This happened in the past with the
XmlValidatingReader. All processing would need to go exclusively through the
abstract classes such as XmlReader.

I believe such an approach to XML handling looks more compelling and is
better prepared for future evolution of XML processing.

What do you think?

--
Daniel Cazzulino [MVP XML]
Clarius Consulting SA
http://weblogs.asp.net/cazzu
http://aspnet2.com