* 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'.
This introduces support for partial applications on dynamic functions.
The test cases are comprehensive and the implementation should be
quite stable.
Even though the base higher-order function implementation was based on
the work of Dimitre Novatchev[0], I have chosen a different route for
partial application: Novatchev's method relies on storing partially
applied arguments as nodes, together with their types. The types are
detected the best they can be, with accuracy varying wildly depending
on whether a schema-aware processor is present.
But regardless, that method would not retain node context.
Sequences, however, do. By using sequences, we allow the processor to
retain all type and context information perfectly without any
additional work that is inaccurate, adds complexity, and likely to
cause subtle problems. It will also support any types that we are
unaware of. As Novatchev mentions:
The argument type-detection that f:curry() uses has been implemented
only for the builtin XML Schema datatypes. It will not recognize the
user-defined type of an argument, which can be created by an user of
a Schema-Aware (SA) XSLT 2.0 processor.[0]
This is not a problem with hoxsl.
[0]: http://conferences.idealliance.org/extreme/html/2006/Novatchev01/EML2006Novatchev01.html
Mike Gerwitz