[XSL-LIST Mailing List Archive Home]
[By Thread]
[By Date]
Intuitively, and simply, the functional aggregator of "keys" would aggregate each value it encounters and not have some implied context for the values of that set. IOW, there is no intuitive requirement for the context specifier. It seems unnecessary even in the context of a functional language.
The problem recurs in functional (the battle between implication and explication) and, as far as possible, it is better to reduce this problem. It will trip up programmers and add to the testing burden.
The issue, as I understand it here, is the scope of execution. Whether it is the processing transaction or the individual document. I am simply observing that, for global keys, the scope of the processing transaction is the intuitive scope of execution.
If you accept that a transaction will, ultimately, want to process multiple documents or documents with multiple components then it should be clear that the implied context introduces referencing difficulties. I suspect, and correct me if I am wrong, that the initial design parameters for XSL gave this question less consideration. And while the solution in this thread has solved my particular challenge it does not generalize.
On Jan 27, 2008, at 8:00 AM, Florent Georges wrote:
Re: [xsl] combining multiple documents
|
Subject: Re: [xsl] combining multiple documents From: Steven Ericsson-Zenith <steven@xxxxxxxxxxxxx> Date: Sun, 27 Jan 2008 13:18:11 -0800 |
Intuitively, and simply, the functional aggregator of "keys" would aggregate each value it encounters and not have some implied context for the values of that set. IOW, there is no intuitive requirement for the context specifier. It seems unnecessary even in the context of a functional language.
The problem recurs in functional (the battle between implication and explication) and, as far as possible, it is better to reduce this problem. It will trip up programmers and add to the testing burden.
The issue, as I understand it here, is the scope of execution. Whether it is the processing transaction or the individual document. I am simply observing that, for global keys, the scope of the processing transaction is the intuitive scope of execution.
If you accept that a transaction will, ultimately, want to process multiple documents or documents with multiple components then it should be clear that the implied context introduces referencing difficulties. I suspect, and correct me if I am wrong, that the initial design parameters for XSL gave this question less consideration. And while the solution in this thread has solved my particular challenge it does not generalize.
With respect, Steven
On Jan 27, 2008, at 8:00 AM, Florent Georges wrote:
Steven Ericsson-Zenith wrote:
I do - at least I think I do - understand the implementation, I am just expressing a discomfort with the counter intuitive nature of the third parameter in key.
Could you please explain more precisely what would be, for you, an intuitive definition of keys (with or without the third parameter)?
Regards,
--drkm
_____________________________________________________________________________
Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail http://mail.yahoo.fr
| Current Thread |
|---|
|
| <- Previous | Index | Next -> |
|---|---|---|
| Re: [xsl] combining multiple docume, Florent Georges | Thread | Re: [xsl] combining multiple docume, Florent Georges |
| Re: [xsl] XSL-FO Doctype Problem, Karl Stubsjoen | Date | Re: [xsl] combining multiple docume, Florent Georges |
| Month |
Keywords