DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=27301>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=27301

FilterTransformer: Generates not matching block tags





------- Additional Comments From [EMAIL PROTECTED]  2004-03-09 00:48 -------
I get another result. That might be due to a more intelligent Xalan (finally - I
often saw results like above):

<?xml version="1.0" encoding="ISO-8859-1"?>
<files xmlns:i="http://apache.org/cocoon/include/1.0";>
  <block xmlns="http://apache.org/cocoon/include/1.0"; id="1">
    <i:include src="file1.xml"/>
    <i:include src="file2.xml"/>
    <i:include src="file3.xml"/>
    <i:include src="file4.xml"/>
  </block>
</files>

Can you try it with Xalan 2.6?

Though I don't like the output above. How do you want to match on block later on
in the pipeline if you only can guess in which namespace it is?

Therefore I will commit a patch so that the result looks like the followign:

<?xml version="1.0" encoding="ISO-8859-1"?>
<files xmlns:i="http://apache.org/cocoon/include/1.0";>
  <block id="1">
    <i:include src="file1.xml"/>
    <i:include src="file2.xml"/>
    <i:include src="file3.xml"/>
    <i:include src="file4.xml"/>
  </block>
</files>

Maybe we should put block in its own namespace, but first I will patch this thing.

Joerg

Reply via email to