Bad Monday and XInclude.NET development

| No Comments | No TrackBacks

When your hard disk dies Monday morning, that's nice week start. Low type tasks on recovering your data, sources, reinstalling and configuring all the stuff you cannot work without... Refreshing.

Basically I've recovered already. Surprisingly I cannot now install Office 2003, it says "You've got McAffee VirusScan Enterprise installed, Office 2003 Pro cannot be installed on the same machine with that crap." Hmmmm... Anybody seen that? I failed to google any workarounds.

Anyway, back to XML. I've been fixing one nasty bug in XInclude.NET and implemented at the same time document caching (those loaded into memory anyway - when XPointer involved). It's very natural indeed to have several partial includes from the same document:

<xi:include href="books.xml" xpointer="xpointer(/catalog/@title)"/>
<xi:include href="books.xml" xpointer="xpointer(/catalog/@count)"/>
For selecting fragment of a document, identified by XPointer pointer, XInclude.NET translates XPointer to XPath, loads the document into XmlDocument and evaluates the XPath selection. Obviously XmlDocument should be cached in this scenario.

Well, may be also there is a point to cache documents, which are included as a whole. That's not so common to include the same document more than once, but who knows. That means no more streamng include, while allows to implement XInclude intra-document references I was complaining about. I think that's nice to have option.

So I'm planning to implement non-streaming XInclude mode for XInclude.NET too. In fact that's amazingly simple to build in-memory XML processing on top of streaming one. Actually all I need to do is to cache source document and pipe it to XInlcludingReader via XmlNodeReader. That's it.

Having that mode XInclude.NET would be able to perform XML Inclusions in streaming (w/o support for intra-doc refs) or non-streaming way (full support). Users might measure and decide which mode is appropriate for their particlular project.

If I'd be not so lazy it's doable to move from XmlDocument to XPathDocument, gaining approximately 30% more of perf. For that I need XmlReader over XPathNavigator. I've seen several, so why not.

The bottom line - XInclude.NET 1.3 is coming.

Related Blog Posts

No TrackBacks

TrackBack URL:

Leave a comment