You are viewing a plain text version of this content. The canonical link for it is here.
Posted to taglibs-dev@jakarta.apache.org by "Mark R. Diggory" <md...@latte.harvard.edu> on 2004/07/18 19:23:53 UTC
JSLT XML always falls short in capability.
For anyone who has worked with JAXP, they find the behavior of JSTL XML
woefully inadequate in terms of configuring the underlying parser. I
suspect that the JSTL spec maintains very little reference to
configuring the underlying parser factory or transformer factory. This
results in the usage of the JSTL XML being limited to only the most
simplistic of parsing situations due to a tremendous amount of hardcoded
behavior.
I could build a list of issues that cause JSTL XML to be a poor solution:
1.) No validation, even if the underlying parser supports it.
2.) No ability to set underlying parser/transformer features.
3.) No ability to customize error handlers / listeners
4.) No ability to take advantage of parsing SAX or InputStreams in the
Transformer implementation, thus no capability to take advantage of
features such as XSLT preview to make memory usage during parsing more
efficient.
5.) JSTL restricts the content of x:transform tag to only be x:param
tags, thus no iterative core tags can be used to automate parameter
setting i.e.
<x:transform>
<c:for-each ...>
<x:param .../>
</c:for-each>
</x:transform>
Clearly these issues make JSTL a poor solution for any sort of advanced
XML parsing/transformation, this results in all but the most simplistic
XML parsing solutions having to be implementated outside fo JSTL either
in scripts or java classes (Servlets, Filters, Actions, Beans etc) using
JAXP directly.
-Mark
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
Re: JSLT XML always falls short in capability.
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
Thanks, I'll take a look and join in the discussion there.
-Mark
Justyna Horwat wrote:
> I know that the current implementation has many shortcomings. Right now
> I'm getting familiar with the JAXP 1.3 specification. I'm not versed in
> JAXP to be able to have a discussion about the behavior yet but I'm
> definitely going to keep your suggestions in mind when looking at it.
>
> I went ahead and brought up your concerns to the JSTL specification
> leads. They are always looking for use cases and ways to improve the
> next version of JSTL.
>
> The specification leads are always looking for input. You can join the
> discussion here:
>
> http://jstl-spec-public.dev.java.net
>
> Thanks,
>
> Justyna
>
> Mark R. Diggory wrote:
>
>> For anyone who has worked with JAXP, they find the behavior of JSTL
>> XML woefully inadequate in terms of configuring the underlying parser.
>> I suspect that the JSTL spec maintains very little reference to
>> configuring the underlying parser factory or transformer factory. This
>> results in the usage of the JSTL XML being limited to only the most
>> simplistic of parsing situations due to a tremendous amount of
>> hardcoded behavior.
>>
>> I could build a list of issues that cause JSTL XML to be a poor solution:
>>
>> 1.) No validation, even if the underlying parser supports it.
>> 2.) No ability to set underlying parser/transformer features.
>> 3.) No ability to customize error handlers / listeners
>> 4.) No ability to take advantage of parsing SAX or InputStreams in the
>> Transformer implementation, thus no capability to take advantage of
>> features such as XSLT preview to make memory usage during parsing more
>> efficient.
>> 5.) JSTL restricts the content of x:transform tag to only be x:param
>> tags, thus no iterative core tags can be used to automate parameter
>> setting i.e.
>>
>> <x:transform>
>> <c:for-each ...>
>> <x:param .../>
>> </c:for-each>
>> </x:transform>
>>
>> Clearly these issues make JSTL a poor solution for any sort of
>> advanced XML parsing/transformation, this results in all but the most
>> simplistic XML parsing solutions having to be implementated outside fo
>> JSTL either in scripts or java classes (Servlets, Filters, Actions,
>> Beans etc) using JAXP directly.
>>
>> -Mark
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
>
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
Re: JSLT XML always falls short in capability.
Posted by Justyna Horwat <Ju...@sun.com>.
I know that the current implementation has many shortcomings. Right now
I'm getting familiar with the JAXP 1.3 specification. I'm not versed in
JAXP to be able to have a discussion about the behavior yet but I'm
definitely going to keep your suggestions in mind when looking at it.
I went ahead and brought up your concerns to the JSTL specification
leads. They are always looking for use cases and ways to improve the
next version of JSTL.
The specification leads are always looking for input. You can join the
discussion here:
http://jstl-spec-public.dev.java.net
Thanks,
Justyna
Mark R. Diggory wrote:
> For anyone who has worked with JAXP, they find the behavior of JSTL XML
> woefully inadequate in terms of configuring the underlying parser. I
> suspect that the JSTL spec maintains very little reference to
> configuring the underlying parser factory or transformer factory. This
> results in the usage of the JSTL XML being limited to only the most
> simplistic of parsing situations due to a tremendous amount of hardcoded
> behavior.
>
> I could build a list of issues that cause JSTL XML to be a poor solution:
>
> 1.) No validation, even if the underlying parser supports it.
> 2.) No ability to set underlying parser/transformer features.
> 3.) No ability to customize error handlers / listeners
> 4.) No ability to take advantage of parsing SAX or InputStreams in the
> Transformer implementation, thus no capability to take advantage of
> features such as XSLT preview to make memory usage during parsing more
> efficient.
> 5.) JSTL restricts the content of x:transform tag to only be x:param
> tags, thus no iterative core tags can be used to automate parameter
> setting i.e.
>
> <x:transform>
> <c:for-each ...>
> <x:param .../>
> </c:for-each>
> </x:transform>
>
> Clearly these issues make JSTL a poor solution for any sort of advanced
> XML parsing/transformation, this results in all but the most simplistic
> XML parsing solutions having to be implementated outside fo JSTL either
> in scripts or java classes (Servlets, Filters, Actions, Beans etc) using
> JAXP directly.
>
> -Mark
>
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org