Later tonight I will be checking in some xinclude support. Currently XInclude only works against the UI dom. This is one approach, there are two, which I will go over.
Approach 1: <include> tags work in the UI document and other documents that detect when children are added and removed. (This is what I am checking in) How: When an <include> tag is added, make a request for the content, either synchronously or asynchronously. When the content comes back remove the <include> tag and replace it with the contents. Pros: Well defined. Can be synchronous or asynchronous. (If asynchronous we can draw whatever part of the screen is ready, then draw the rest after that content is available) Simple implementation. Cons: <include> tag will only work in documents managed by a plugin document handler. For example, the following will not work: <xal> <xi:include href="someMcoDeclarations.xml"/> ... </xal> Approach 2: <include> tags work everywhere. How: We detect <include> tags during SAX parsing. When we hit an include tag we synchronously request the content, then substitute in the new content. So the document we build up that then gets handed off to processing already has all the resolved content in it. Pros: include tags will work basically anywhere you care to stick them. Cons: Asynchronous resolution not possible as we must build up the entire processed document before we start processing on it. The strategy here is to resolve all included tags immediately, then process document. If we switch to letting the built-in XML support handle building our initial document this may not work or may require a second pass to look for include tags. --- I feel that approach 1 is more flexible as it allows us to resolve content asynchronously, and is simply implemented as another bridge mapping, and covers the most common use case (including stuff in the UI document) better in that it can resolve synchronously or asynchronously. So that is what I am checking in for now. James Margaris
