XSLT has now
been in existence for six years, formally, which means that it is now
being
used by people who have absolutely no clue what they're working with,
have
no real grounding in the technology or its imperatives, and are looking
for
turnkey solutions from vendors.
I'd think a lot of adapters probably start off as generalists. Or to put
it another way, some generalists have it in them to become adapters;
maybe even higher. I mean that I would hope that any generalist is a
generalist by necessity but has some skills in which they could well be
described as a specialist, expert, adapter, what-you-will. This is in
fact what applies to me, I am in many ways a generalist over a wide
array of disciplines, but every now and then I find a particular
discipline that appeals to me and I begin to learn it in the depth.
"Oh, you must be one of the five people on the planet who know how to
work
with XSL."
This would seem to be a weird comment coming from Microsoft; I can
understand you getting floored.
In order to set XSLT
parameters, you have to instantiate a secondary XPathNavigator object
to
retrieve an object that lets you assign parameters, that then needs to
be
passed as an argument into the Transformer object -- it's
understandable
from a class perspective, but is so friggin complex that you REALLY
need to
understand what you're doing just to do what should be a simple action
(and
IS in the corresponding Transformer class in Java.
I don't much care for the use of XPathNavigator in .Net to assign
parameters, but not for the reasons you name; actually for what I've
done so far which admittedly has not been especially difficult (I tend
to add my parameters as a nodeset of parameters), I can't see much
difference between creating a Navigator and passing it an
XsltArgumentList and creating an object "msxml2.xsltemplate.4.0",
loading a DOM into that object, creating a processor and then passing
that processor my parameters.
The thing which really bugs me .Net vis-à-vis passing of parameters is
that when one passes a nodeset - so far as I have experience - you
cannot access that nodeset with node-set(), instead you query it
straight on with $paramsNode/params/param and so forth, which irritates
me because I see it as creating a debugging problem, in that if you
create an inline nodeset, again in my experience using .Net, you have to
access it via node-set(); it's those kinds of things that I think
demonstrate an imbalanced logic on the implementation side, and that for
me at least makes it harder to design a good solution in that
environment where xslt is an integral part of the solution.
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list