* record.xsl: added
This only support unnamed slots.
* record.xspec: added
Notice the documentation style: all sentences and clauses of compound
sentences are on their own lines, indented relative to their parent. This
produces much better diffs when things change.
I began development of Hoxsl under my employer, LoVullo Associates, which
holds copyright to the commits prior to this one. This project was largely
planned on my own time and represents an ideal; there has been no time to
continue its disciplined developement under LoVullo, I do not expect for
there to be time to develop this project to my liking, and I don't expect
others within the organization to maintain and improve upon it once I'm
gone.
As such, I'm forking this project and developing it personally outside of
LoVullo Associates. I don't use XSLT outside of LoVullo, so this
realistically is still a project that will only be used there (by myself),
and I can't say whether I'll continue to maintain this project after I
leave. But similar to how I developed GNU ease.js on my own time---to
benefit software I write at LoVullo---it doesn't make sense to develop the
project on unpaid overtime for no reason, when I'm not even being asked to
do so.
It is therefore in my best interest, to ensure that Hoxsl will always remain
Free (as in freedom), that I continue development as a personal project.
With all that said, Hoxsl will be used for other Free public projects at
LoVullo---such as TAME---that I will continue to liberate and may be useful,
even if only from an academic perspectve, outside of LoVullo.
As if I didn't already have enough unfinished things on my plate...
The submodule is inconvenient and requires awkward project updates for
changes that might be frequent (as it is developed alongside this project).
If we become worried about BC breaks, then we'll do a version check.
The documentation will begin to be modelled after Knuth's concept of
literate programming. The document is not in the best state, but at least
it is now being generated.
This is aggressively tested in every instance where it could be affected,
since any mishandling of this value would be incredibly dangerous (best
case, it would blow up and abort; worst case, data are interchanged between
refs).
This produces a short-hand partial application (well, it'd be more accurate
to call the use of `f:apply' or `f:partial' long-hand, since this is most
natural).
This is intended as a convenient shorthand:
```xml
<!-- these two are identical -->
<sequence select="f:apply( my:func(), $x, $y )" />
<sequence select="my:func( $x, $y )" />
```
As operations on dynamic function references become more complex, and since
evolution of the reference structure is planned to evolve, maintaining an
abstraction is vital for both grokking and maintenance.
Previously, a separate `@partial' attribute was added to the ref and the
`@arity' maintained. Unfortunately, this coupled `f:arity' with
`f:partial', which is unnecessary, considering that partial application is
supposed to conceptually yield a new function, which should be transparent
to `f:arity'.
Mike Gerwitz