Re: Proposal: replace here documents with a component

Norman Walsh wrote:
> I wouldn't dream of removing the functionality of "here documents",
> but there's a balance to be made between simplicity and functionality
> and I think we've got it wrong with respect to here documents in the
> current draft.
> 
> The fact that we have three ways to describe inputs, and the fact that
> one of them (here documents) is very different from the other two
> (attributes) makes the draft quite a bit more complicated.
> 
> It also imposes (unnecessary, IMHO) constraints on the design of the
> language. Consider the current draft's position on "choose" as opposed
> to "for-each". Because we put the context attributes directly on the
> "choose" element, you can't use a here document for choose. Because we
> used a "declare-input" for for-each, you can.

While that might be unfortunate in some odd situations, the utility of
having "here" documents *exactly* where they are using is very
important and I don't want that facility to go away.

I'm not in favor of this proposal as it moves statically known inputs
to dynamically known inputs and that means that component-level
optimizations (e.g. pre-compiling the XSLT) are completely lost.

I'd also like to note that here documents are much like input bindings
that point to uris and it is the input-to-output binding that is
different as it is dynamically "populated".  That is, you can statically
find inputs pointed by URIs much like you can for here documents and
that allows certain components to optimize (and throw errors) by
using those static inputs at compile time (e.g. compile an XSLT
transform).

--Alex Milowski

Received on Thursday, 21 September 2006 16:10:30 UTC