Bug 14841 - <x:parse/> does not allow redefinition of default namespace
Summary: <x:parse/> does not allow redefinition of default namespace
Status: RESOLVED INVALID
Alias: None
Product: Taglibs
Classification: Unclassified
Component: Standard Taglib (show other bugs)
Version: 1.0
Hardware: PC All
: P3 enhancement (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-11-26 09:35 UTC by Daniel Frei
Modified: 2005-03-20 17:06 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Frei 2002-11-26 09:35:54 UTC
Please add a new attribute to <x:parse> which allows the assignment of a prefix 
for the default namespace. Otherwise it is not possible to access elements 
belonging to the default namespace from other <x:.../>-tags.

Example response from a webservice (simulated via <c:set/>:

<c:set var="responseXML">
<?xml version="1.0"?>
<Message Version="1.0" xmlns="http://some_ns_url">
  <Transport/>
  <MessageHeader>
    <Response/>
    <Key></Key>
  </MessageHeader>
  <MessageBody>
    <GetPackageList.Response>
      <Exception>
        <MainCode>2</MainCode>
        <SubCode></SubCode>
        <Type>T</Type>
        <Subject>Error: Unknown package location</Subject>
        <Description></Description>
      </Exception>
    </GetPackageList.Response>
  </MessageBody>
</Message>
</c:set>

<x:parse xml="${responseXML}" var="parsableXML"/>

<x:out 
select="$parsableXML/Message/MessageBody/GetPackageList.Response/Exception/Subje
ct"/>


The above <x:out> will not find the Subject-element unless one could reassign 
the default namespace in the responseXML to e.g. xmlns:ns1="http://some_ns_url"
Comment 1 Shawn Bayern 2002-11-26 13:14:46 UTC
This bug-tracking system is for bugs with the JSTL implementation; this is a 
request for a new feature from the JSTL specification.  You should normally 
mail jsr-52-comments@jcp.org with such suggestions, but the JSR-52 expert group 
(the one responsible for JSTL) has already received this suggestion and is 
working on a solution for JSTL 1.1.