At 2013-06-30 09:49 +0200, Wolfgang Laun wrote:
I decided to implement this in Perl and was hoping to be able to
compare this with an equivalent implementation in XSLT, concentrating
on ease of development and maintainability. Ken's implementation
<https://www.CraneSoftwrights.com/resources/#csv> filled the XSLT slot.
Ken's solution falls short on a few points I was able to add easily. I can't
say how difficult they would be to add to Ken's existing solution - it might
not be a matter of minutes for some of those add-ons.
Off-list I've corresponded with Wolfgang and I've taken the time to
implement in XSLT the features he was able to add easily to the Perl
I've also updated the readme-Crane-ParseCSV.html documentation to
illustrate scenarios of working with the invocation parameters. Note
that the library also implements files with "Tab separated values"
and I've parameterized the CSV file so as to exploit the code rather
than duplicate the code as in the earlier library.
Ken used a proprietary (?) solution for embedding documentation that can
be extracted into HTML.
It isn't proprietary, but it is my own design and implementation and
I've made it open and available since 2004. It is called XSLStyle
and is available here:
All of my customer XSLT documentation is generated using this, plus
using this improves the quality of my stylesheets because I have
coded "stylesheet writing rules" that are checked while creating the
output HTML. I don't deliver my code until these business rules are
checked and I haven't omitted anything from my stylesheet (such as
documentation for a particular top-level construct, or declaring
types of global variables).
Note that XSLStyle defines only scaffolding within which stylesheet
documentation is maintained in one of three vocabularies: DocBook,
DITA or XHTML. I typically use DocBook, but I've written the DITA
and XHTML environments for other users of XSLStyle.
To see a client's example of my documentation I delivered for
stylesheets I wrote (interestingly, one of the stylesheets was
obliged to be written using XML 1.1), they've posted it here:
XSLT is "special purpose" for XML handling and consequently easy to use,
but it isn't better than the average language for string processing.
Granted, but in some platforms it may be the only available tool in
the toolbox. Not that I advocate using a hammer to pound a screw in
carpentry, but if you are using a toolset where you are obliged to
use XSLT for string processing, it is nice that string processing is
available in XSLT 2.
Thank you, Wolfgang.
. . . . . . . . . Ken
Contact us for world-wide XML consulting and instructor-led training |
Free 5-hour lecture: https://www.CraneSoftwrights.com/links/udemy.htm |
Crane Softwrights Ltd. https://www.CraneSoftwrights.com/s/ |
G. Ken Holman mailto:gkholman(_at_)CraneSoftwrights(_dot_)com
Google+ profile: https://plus.google.com/116832879756988317389/about |
Legal business disclaimers: https://www.CraneSoftwrights.com/legal |
XSL-List info and archive: https://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: https://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>