Thanks Syd, this really does open up a tin of annelids...

1. David's example returns an <lg> in the TEI namespace, so you probably 
don't want to wrap the <xi:include> *inside* an <lg>

2. I'm not sure in what sense "the semantics are defined for you" with 
xInclude: it seems to me that the semantics are precisely NOT defined 
(if by "semantics" we mean the element type) by xinclude, which is why 
it's useful for filling in bits of a structure in stand-off mode.

3. @copyOf has the interesting property that whatever is returned by its 
target replaces the element which carries it; hence (a) what is returned 
must be an well formed element (b) its semantics (tagname) are explicit 
in the document -- surely a good thing!

4. The fallback mechanism of xi:include is useful, certainly, but I'm 
not sure how helpful it is in the general case. If the pointer to the 
resource you need is broken, in general no amount of falling back is 
going to help you. Presumably though a fallback in xi:include does 
permit you to supply another xi:include e.g. to go and try another location?

Syd Bauman wrote:
> The other difference, of course, between 
>      <xi:include href=""/>
> and either of
>      <ptr target="" rend="transclude"/>
>      <ptr target="" type="include"/>
> is that for the <xi:include>, the semantics are defined for you. For
> the <ptr> you need to define the semantics yourself, presumably in
> the <elementSpec> for <ptr> in your ODD.
> The TEI also defines a generic mechanism that could be used for
> inclusion, but it requires duplicating the "root" element of that
> which is being included:
>      <lg copyOf=""/>
> And it involves tag abuse in order to have a fallback:
>      <lg copyOf="">
>        <l>WARNING: inclusion of 'random-dickinson.xqy' failed!</l>
>      </lg>
>> The difference between this approach and that based on xInclude is
>> that the latter takes place at a different time in the construction
>> of the document from the former. This may not matter for most
>> existing TEI applications, but you might care one day that the
>> document you are assembling should all be assembled synchronously.