[
Lists Home |
Date Index |
Thread Index
]
>
> >[Eliotte Rusty Harold]
> >Much more important is that his test case is:
> >
> >XML documents contain (among other things) text phrases that must be
> >converted into equivalent LaTeX phrases. Some text phrases, such as "&"
> >and "$" have special meaning to LaTeX and thus must be escaped during
> >processing. Others represent text idioms like "(C)" that must be mapped to
> >their LaTeX equivalents ("\copyright{}").
> >
> >In other words he wants to do string manipulations on unmarked up text.
> >Furthermore, his output format is not XML, but LaTeX. Moertl is taking
> >XSLT and using it to do exactly what it was designed not to do. He is
> >completely confused about what the intended purpose of XSLT actually is.
> >It was never intended to do what he wants it to do. It shouldn't be a
> >surprise he has trouble. Nor should this be considered a knock on XSLT,
> >since none of his use cases are something XSLT was ever intended to handle.
>
> Oh I dunno. I believe he has a very good point. XSLT has trouble
> manipulating things that are between the tags.
Well, C has trouble with string processing, Java has problems with generic programming, etc. XSLT at least is careful to manage its ambvitions WRT what lies between the tags. I think it does provide good escaping, though, so down to the pertinent part of your post...
> There are those who would argue (and I was one of them in a previous life)
> that the way to fix this
> is to provide an "escape" into a procedural environment - be it an embedded
> scripting language
> or an escape to roll-your-own extension functions.
First of all, procedural methods are usually pretty bad afor text processing. It's easy to be so used to
for char in string
begin
hack at char
increment string
end
that you forget how terribly inefficient and error-prone it is.
so-called "scripting languages" tend to be far superior to the so-called "application languages" by providing a built-in declarative approach to string processing: regular expression libraries.
But this is beside your point, I know. I just had to nit pick :-)
> I no longer believe this is a good answer and, as I said at Paul Prescods
> excellent XSLT
> talk in Orlando, I believe the answer lines in pipeline architectures which
> facilititate
> the mixing and matching of different XML processing paradigms in a single
> execution context.
Wow. If I understand rightly, is sort of what the XSL WG was going for in some of the 1.1 facilities that I and others so loudly protested.
What are the concerns that make you want such? Performance? Maintenance?
It can't be what you wrote above, because XSLT's extension mechanism provides a perfectly fine way to defer some processing to non-XSLT code. The only thing is that the other code is ina different language in a different file. I don't see how melding XSLT with every possible programming paradigm could be a good thing.
--
Uche Ogbuji Principal Consultant
uche.ogbuji@fourthought.com +1 303 583 9900 x 101
Fourthought, Inc. http://Fourthought.com
4735 East Walnut St, Boulder, CO 80301-2537, USA
XML strategy, XML tools (http://4Suite.org), knowledge management
|
