> 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>
This is most certainly a true observation (and I don't think anyone
in the conversation up to now was suggesting that <xi:include> go
inside <lg> -- I certainly wasn't).
> 2. I'm not sure in what sense "the semantics are defined for you"
> with xInclude:
I meant that when a processor or person runs across an <xi:include>
element he, she, or it "knows" what is supposed to happen: the
<xi:include> is to be replaced with the (well-formed tree fragment
of) found by resolving the attributes, or (failing that) the
<xi:fallback> contents. This knowledge comes from the TEI Guidelines
and the W3C XInclude specification. It is not incumbent on the user
of <xi:include> to define for future generations what it means.
> 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!
Right. And property (a) is exactly the same with <xi:include>, where
property (b) is not available with <xi:include>.
> 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?
Yes, an <xi:fallback> can contain an <xi:include>. See
http://www.w3.org/TR/xinclude/#fallback-example. An <xi:fallback>
could even contain a
thus mixing-and-matching your inclusion paradigms.