[ExternalModel, NestedModel] Why not include with @id, @src and @ref?

Just to keep the discussion going here on external models and nested 
models, I've said previously that I did not think having src on the outer 
model element was sufficient for most reasonable use cases (i.e. anything 
but a small model that doesn't make much use of constraints).

In [1], I provided a significant elaboration of all the types of things I 
was trying to achieve, such as consuming constraint bundles multiple times 
by context and consuming XForms-based web service definitions.

[1] http://lists.w3.org/Archives/Public/public-forms/2009Jun/0042.html

Previously, Erik suggested using XInclude, which I think won't get to my 
context-based consumption case, and Raman also advocated not constraining 
ourselves to external specifications if they don't do exactly what we want 
and/or add too much complexity.

It seems reasonable, then, to ask whether we just need a simple <include> 
element with semantics that we define as follows:

1) Using element include ensures no confusion with xforms semantics on 
models; there's just one outer model.

2) @id on include provides a referencing conduit into the id space of the 
included content. 
i) References within included content could work as normal, e.g. 
instance("someID")/blah
ii) References from included content out to the inclusion stack out to the 
outermost model could also work without further qualification
iii) References into include content from the outside could add a 
parameter to instance(), e.g. instance("someInclude", "someID"). 
iv) The instance function can have as many params as needed to handle 
inclusion nesting (i.e. drilling *into* the inclusion stack).

3) @src attribute pulls content into the model from the external URI in 
the ID subspace

4) If given, @ref attribute provides context node for included content, 
overriding root element of first instance included in containing model.

The simple case Steven wanted looks like this:

<model>
    <include src="model.xml"/>
</model>

so it is still achievable with minimal overhead.  Given the rules above, 
all the use cases I have on my list in [1] are covered, too. 

Can anyone think of others?  Any reason not to proceed with this idea?

John M. Boyer, Ph.D.
STSM, Interactive Documents and Web 2.0 Applications
Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com 

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
Blog RSS feed: 
http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw