[
Lists Home |
Date Index |
Thread Index
]
Joe English wrote:
> My impression is that XInclude is a wrong-size-fits-nothing
> kind of thing. Other specs that need XInclude-like functionality
> often need something with _slightly_ different semantics, and
> end up specifying it themselves instead of reusing XInclude
> (<xsl:import>, for instance).
>
> I've developed a number of vocabularies that could have used
> XInclude, but ended up using a simpler ad-hoc solution instead.
There are use cases for XInclude beside using it in a vocabulary.
An obvious one requires include processing before validation, i.e.
as part of the parser with current state of the art. This is
quite of interest for people who want to be flexibly splitting
their documents into various parts the same way entities allow,
but don't want to use entities (most probably because they want
to validate against a WXS or RNG schema and don't want to use
a DTD at all) nor want to clutter their vocabulary with include
elements.
Another use case is content aggregation using a stand-alone
XInclude processor which agregates validated content from
various sources. The obvious advantages are that each source
can uses it's own schema for validation, they can even use
different schema languages, and there is no need to develop
a schema for the aggregated content.
Well, if you are doing an XSLT after aggregation, you could
use document() instead.
J.Pietschmann
|
