I haven't been keeping up totally with this thread (I've been down with yet
another cold the last few days), but it's clear to me that the serializers
should handle start/endPrefix. In fact, it is probably more efficient for
the ResultTreeHandler to use start/endPrefix instead of xmlns: attributes.
Relying on xslns: attributes should only be done as a fallback mechanism.
> 2?) When Xalan applies a stylesheet, it puts the namespaces as attributes
(where and how I could not find, sadly)
In the ResultTreeHandler.
Unfortunately, I don't think your
http://nagoya.apache.org/bugzilla/showattachment.cgi?attach_id=232 fix is
sufficient. The namespaces should be tracked to avoid duplicates, I think.
Or maybe not. I have to think on it a bit more. At least they have to be
tracked so that xmlns: attributes won't cause a duplicate.
Or should we disallow xmlns: attributes altogether?
I guess one reason I didn't implement start/endPrefix in the first place is
because I didn't want the serializers to worry about namespace resolution.
Having to track namespace resolution will be yet another performance hit
(but maybe not if we do it right).
Michel, you might take a look at startElement and startPrefixMapping in
org.apache.xml.dtm.ref.sax2dtm.SAX2DTM. By pushing the prefix mappings
into a Vector, it can then check for the duplicate if it finds an xmlns:
attribute. Is this a better way to do things?
-scott
"Michel Lehon"
<Michel.Lehon@Out To: <[EMAIL PROTECTED]>
wares.com> cc: (bcc: Scott Boag/CAM/Lotus)
Subject: RE: Namespaces are ignored
in SerializerToXML...
07/26/2001 05:31
AM
Please respond to
xalan-dev
Myriam,
Joseph,
Some more information I could gather... maybe it'll talk more to you than
me
as I have some trouble understanding all it all works.
anyway here it goes.
1?) As Joseph noted, the XML serialzer can output the namespaces without
reliyng on start/end prefix mapping. But it means that the prefixes are
passed as attributes. After some more check of the code (and some time in
the debugger), I could see that the XML serializer is indeed working OK
without any patch, as long as it gets the namespaces as attributes.
2?) When Xalan applies a stylesheet, it puts the namespaces as attributes
(where and how I could not find, sadly), which means the XML serializer is
working OK when called after the transformation of a stylesheet. However
when a Transformer is requested without a stylesheet (i.e. through
SAXTransformerFactory.newTransformerHandler()) then it does not seem (again
could not find evidence in code) to convert the namespaces to attributes
(in
fact is uses the TransformerIdentityImpl... where the problem might be.).
If
I run my application with an identity stylesheet it works (I mean I get
namespaces in my xml output), If I rely on the identity transform of
newTransformerHandler, it does not work (no namespace in output).
3?) I still wonder about namespaces as attributes, Xalan does it that way,
Xerces (1.4.2) does not...
Thanks for reading, I hope it helps to pinpoint the problem.
Michel.
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, 25 July, 2001 22:47
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: RE: Namespaces are ignored in SerializerToXML...
>
>
>
> >And the SerializerToXML.startPrefixMapping method is still empty so I
> >guess it did not fix the problem.
>
> The fact that the serializer ignores the start/endPrefixMapping calls
> doesn't necessarily mean it "ignores namespaces". All the information
> _should_ be available from the startElement and endElement calls, and the
> serializer ought to be able to do the right thing.
>
>
> > Is it correct to consider 'xmlns:java' an attribute ???
>
> Yes. Note that the prefixMapping feature of SAX is documented (in
> http://xml.apache.org/xalan-j/apidocs/org/xml/sax/ContentHandler.html) as
> something most applications won't need. It's primarily intended to
support
> handling of prefixes that appear inside document _content_.
>
> The serializer isn't doing anything along those lines, so discarding
these
> events is perfectly reasonable and the fact that this method is empty is
> probably not a bug.
>
> That doesn't necessarily mean that nothing's wrong. It does mean we
should
> take a step back and get a testcase that demonstrates the real problem,
> then use that to determine whether the bug is in the serializer or in the
> data being fed to the serializer.
>
> What's happening that shouldn't be, and how can we reproduce it for
> analysis?
>
>
>
>
