On XInlcude.NET project again

Kirk Allen Evans's asking hard questions:

Should there be an XIncludeNodeList implementation that is the product of the merged Infosets? Or is this irrelevant since it would only apply to a fully-loaded DOM instance, which should already have been loaded?

I believe XInclude should keep low level of XML processing - just after XML parsing, before (or optionally after) validation, and surely before DOM or XPathDocument building and XSL transformations. This way it can stay simple and transparent.

Should loading an XIncludeDocument be in any part asynchronous?

Hmmm. What if we just feed XmlDocument through XIncludeReader to preserve XmlDocument own async loading logic?

Should the first version of XIncludeReader support XPointer? If so, to what degree? Should we only support the XPointer elements() scheme?

Well, XInclude rec requires (must level) support for XPointer Framework (probably it's about shorthand pointer) and element() schema. But I'm not sure about the very first version. Many other XInclude implementations don't support XPointer, so it's not a problem to omit it for a while. But certanly we have to take into account XPointer processing in XInclude.NET even in the first version.

I guess this all boils down to answering "How complete should revision 1 be?"

Yeah, that's the key question. Well, I personally have no idea, probably no support for XPointer at all should be our first milestone, why not?