Re: Saxon broken -- DOMStreamer question

[Bruno Dumon <br...@outerthought.org>]

On Sun, 2003-03-16 at 09:02, Jeff Turner wrote:
> Hi,
> 
> Currently, DOMStreamer.setNormalizeNamespaces() is hardcoded to true.
> This fixes the xmlns problem with Xalan, but breaks it with Saxon.
> 
> Shouldn't we be doing the
> AbstractTextSerializer.needsNamespacesAttributes() check in DOMSerializer
> too?

I think it's more related to the "namespace-prefixes" parameter of the
xml-parser component (see the cocoon.xconf). So it would make more sense
to add a method createDOMStreamer to the Parser interface.

But the decission to create xmlns attributes is in fact something that
every SAX-generating component in the pipeline should be aware of and
honor. And AFAIK most/all transformers only generate
start/endPefixMapping events, and no xmlns attributes. So it seems only
logical that the DOMStreamer also shouldn't generate xmlns attributes.

If you want to quickly disable this behaviour in DOMStreamer so you can
get on with your work, just disable the following lines:
String pr1 = pr.equals("") ? "xmlns" : pr;
String qn = pr.equals("") ? "xmlns" : "xmlns:" + pr;
newAttrs.addAttribute("", pr1, qn, "CDATA", ns);

-- 
Bruno Dumon                             http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org                          bruno@apache.org

Re: Saxon broken -- DOMStreamer question

[Jeff Turner <je...@apache.org>]

On Sun, Feb 16, 2003 at 10:21:58AM +0100, Bruno Dumon wrote:
> On Sun, 2003-03-16 at 09:02, Jeff Turner wrote:
> > Hi,
> > 
> > Currently, DOMStreamer.setNormalizeNamespaces() is hardcoded to true.
> > This fixes the xmlns problem with Xalan, but breaks it with Saxon.
> > 
> > Shouldn't we be doing the
> > AbstractTextSerializer.needsNamespacesAttributes() check in DOMSerializer
> > too?
> 
> I think it's more related to the "namespace-prefixes" parameter of the
> xml-parser component (see the cocoon.xconf). So it would make more sense
> to add a method createDOMStreamer to the Parser interface.
>
> But the decission to create xmlns attributes is in fact something that
> every SAX-generating component in the pipeline should be aware of and
> honor. And AFAIK most/all transformers only generate
> start/endPefixMapping events, and no xmlns attributes. So it seems only
> logical that the DOMStreamer also shouldn't generate xmlns attributes.

I agree; that is the default SAX2 behaviour.  DOMStreamer is currently
emulating namespace-prefixes=true, and as the JaxpParser javadoc says, Saxon
doesn't like this:

 * <li>namespace-prefixes (boolean, default = <code>false</code>) : do we want
 *     namespaces declarations also as 'xmlns:' attributes ?<br>
 *     <i>Note</i> : setting this to <code>true</code> confuses some XSL
 *     processors (e.g. Saxon).

So, by switching off xmlns attributes in DOMStreamer, Saxon is happy, and the
needsNamespacesAsAttribute pipe adapts things for Xalan.

I imagine things will still break with Saxon if users switch
'namespace-prefixes' to true in the XML parser, but that is nothing new, and
more of a Saxon enhancement than a Cocoon bug.

Thanks, it's all much less confusing now.

--Jeff

> If you want to quickly disable this behaviour in DOMStreamer so you can
> get on with your work, just disable the following lines:
> String pr1 = pr.equals("") ? "xmlns" : pr;
> String qn = pr.equals("") ? "xmlns" : "xmlns:" + pr;
> newAttrs.addAttribute("", pr1, qn, "CDATA", ns);
> 
> -- 
> Bruno Dumon                             http://outerthought.org/
> Outerthought - Open Source, Java & XML Competence Support Center
> bruno@outerthought.org                          bruno@apache.org
>