[prev in list] [next in list] [prev in thread] [next in thread]
List: xmlbeans-dev
Subject: Re: [saxon] help deciphering stack trace
From: Ben Anderson <benanderson.us () gmail ! com>
Date: 2005-05-13 14:40:19
Message-ID: fc85d7040505130740487d0cd7 () mail ! gmail ! com
[Download RAW message or body]
hi xmlbeans developers,
I was trying to use xmlbeans with saxon and was experiencing a minor
problem. It turns out that xmlbeans isn't quite adhering to the sax
spec.
A minor change fixes the problem:
$ svn diff
Index: src/xmlstore/org/apache/xmlbeans/impl/store/Saver.java
===================================================================
--- src/xmlstore/org/apache/xmlbeans/impl/store/Saver.java
(revision 169803)
+++ src/xmlstore/org/apache/xmlbeans/impl/store/Saver.java (working copy)
@@ -4130,11 +4130,11 @@
}
if (prefix.length() == 0)
- _attributes.addAttribute( "", "", "xmlns", "CDATA", uri );
+ _attributes.addAttribute(
"http://www.w3.org/2000/xmlns/", "xmlns", "xmlns", "CDATA", uri );
else
{
_attributes.addAttribute(
- "", "", "xmlns:" + prefix, "CDATA", uri );
+ "http://www.w3.org/2000/xmlns/", "xmlns",
"xmlns:" + prefix, "CDATA", uri );
}
}
Any objections to the "correctness" of this?
Thanks,
Ben Anderson
On 5/13/05, Michael Kay <mike@saxonica.com> wrote:
> The relevant rule is in the ContentHandler spec:
>
> http://www.saxproject.org/apidoc/org/xml/sax/ContentHandler.html#startElemen
> t(java.lang.String,%20java.lang.String,%20java.lang.String,%20org.xml.sax.At
> tributes)
>
> Specifically:
>
> This event allows up to three name components for each element:
>
> 1. the Namespace URI;
> 2. the local name; and
> 3. the qualified (prefixed) name.
>
> Any or all of these may be provided, depending on the values of the
> http://xml.org/sax/features/namespaces and the
> http://xml.org/sax/features/namespace-prefixes properties:
>
> * the Namespace URI and local name are required when the namespaces
> property is true (the default), and are optional when the namespaces
> property is false (if one is specified, both must be);
> * the qualified name is required when the namespace-prefixes property is
> true, and is optional when the namespace-prefixes property is false (the
> default).
>
> Saxon requires the namespaces property to be true (the default) and
> therefore expects the local name and namespace URI to be present.
>
> Michael Kay
>
>
> > -----Original Message-----
> > From: saxon-help-admin@lists.sourceforge.net
> > [mailto:saxon-help-admin@lists.sourceforge.net] On Behalf Of
> > Ben Anderson
> > Sent: 13 May 2005 14:34
> > To: saxon-help@lists.sourceforge.net
> > Subject: Re: [saxon] help deciphering stack trace
> >
> > Thanks for the explanation Michael. I found the problem - it's in
> > xmlbeans. It's outputting the following:
> > uri:
> > localName:
> > qname: xmlns:menu
> >
> > which obviously doesn't jive with ReceivingContentHandler. You
> > mentioned the SAX spec about requiring local names. Is this the
> > correct reference you were referring to or is there a better reference
> > somewhere:
> > http://www.saxproject.org/apidoc/org/xml/sax/Attributes.html#g
> > etLocalName(int)
> >
> > I'm asking because I'll probably raise this issue to the XmlBeans
> > people and then try to find the problem there. So, what should be the
> > proper output?
> > uri:
> > localName: menu
> > qname: xmlns:menu
> >
> > Thanks again,
> > Ben
> >
> > On 5/13/05, Michael Kay <mike@saxonica.com> wrote:
> > >
> > > >
> > > > I think we're on the right track here - however I'm still a little
> > > > confused. Are you saying that saxon calls a getFeature
> > method on the
> > > > filter?
> > >
> > > I thought, without actually checking, that this message was
> > coming from the
> > > code in Sender.java, which actually calls setFeature() to
> > set the required
> > > features, rather than getFeature() to inspect them.
> > >
> > > But in fact the error message is coming from elsewhere: from method
> > > getNameCode in ReceivingContentHandler.java. This means
> > that either an
> > > element or an attribute (I can't tell which) has been
> > reported across the
> > > SAX interface with a local name of "".
> > >
> > > The SAX spec says the local name is required if the
> > namespaces property is
> > > true, which is the default.
> > >
> > > If Saxon invokes the XML parser, then the code in
> > Sender.java attempts to
> > > force the namespaces property to true, and throws an error
> > if this isn't
> > > possible. This should be enough to ensure that the local
> > name is never
> > > reported as "".
> > >
> > > The other possibility is that the transformation is being
> > invoked in the
> > > form of a JAXP TransformerHandler, in which case Saxon
> > doesn't get a chance
> > > to configure the parser (or filter): in this case it's the caller's
> > > responsibility to configure it correctly.
> > >
> > > So the possibilities seem to be:
> > >
> > > (a) the XML parser/filter is not reporting the local name
> > despite the
> > > namespaces property being true
> > >
> > > (b) Saxon has been invoked as a TransformerHandler, and the
> > application that
> > > created the parser or filter set its namespaces property to false.
> > >
> > > Hope this gets you further to a solution.
> > >
> > > Michael Kay
> > > http://www.saxonica.com/
> > >
> > > I grepped through saxon's source for "getFeature", but only
> > > > found it as a method declaration, not as a method call.
> > Is there a
> > > > way to turn this "getFeature" part off. I know that all
> > the pieces
> > > > support namespaces.
> > > > Thanks,
> > > > Ben
> > > >
> > > > $ find . | xargs grep 'getFeature'
> > > > ./net/sf/saxon/dom/DocumentBuilderFactoryImpl.java:
> > public boolean
> > > > getFeature(String name) throws ParserConfigurationException {
> > > > ./net/sf/saxon/dom/DOMImplementationImpl.java:public Object
> > > > getFeature(String feature,
> > > > ./net/sf/saxon/dom/NodeOverNodeInfo.java: public Object
> > > > getFeature(String feature, String version) {
> > > > ./net/sf/saxon/Filter.java: public boolean getFeature
> > (String name)
> > > > ./net/sf/saxon/Filter.java: * @see #getFeature
> > > > ./net/sf/saxon/TransformerFactoryImpl.java: public boolean
> > > > getFeature(String name) {
> > > > ./net/sf/saxon/xpath/XPathFactoryImpl.java: public boolean
> > > > getFeature(String feature) throws
> > XPathFactoryConfigurationException {
> > > >
> > > >
> > > > On 5/12/05, Michael Kay <mike@saxonica.com> wrote:
> > > > > > org.apache.cocoon.ProcessingException: Failed to execute
> > > > pipeline.:
> > > > > > org.xml.sax.SAXException: Parser configuration
> > problem: namespace
> > > > > > reporting is not enabled
> > > > >
> > > > > This generally means that someone has written an XMLFilter
> > > > that sits between
> > > > > the XML parser and Saxon, and the XMLFilter doesn't
> > > > properly implement the
> > > > > requirement in the SAX specification that it must support
> > > > certain settings
> > > > > of the namespace features. Usually, in fact, the filter
> > does support
> > > > > reporting of namespaces, it just responds incorrectly when
> > > > Saxon calls the
> > > > > getFeature() method to ask which features it supports.
> > > > >
> > > > > Michael Kay
> > > > > http://www.saxonica.com/
> > > > >
> > > > > -------------------------------------------------------
> > > > > This SF.Net email is sponsored by Oracle Space Sweepstakes
> > > > > Want to be the first software developer in space?
> > > > > Enter now for the Oracle Space Sweepstakes!
> > > > > http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
> > > > > _______________________________________________
> > > > > saxon-help mailing list
> > > > > saxon-help@lists.sourceforge.net
> > > > > https://lists.sourceforge.net/lists/listinfo/saxon-help
> > > > >
> > > >
> > > >
> > > > -------------------------------------------------------
> > > > This SF.Net email is sponsored by Oracle Space Sweepstakes
> > > > Want to be the first software developer in space?
> > > > Enter now for the Oracle Space Sweepstakes!
> > > > http://ads.osdn.com/?ad_ids93&alloc_id281&op=ick
> > > > _______________________________________________
> > > > saxon-help mailing list
> > > > saxon-help@lists.sourceforge.net
> > > > https://lists.sourceforge.net/lists/listinfo/saxon-help
> > > >
> > >
> > > -------------------------------------------------------
> > > This SF.Net email is sponsored by Oracle Space Sweepstakes
> > > Want to be the first software developer in space?
> > > Enter now for the Oracle Space Sweepstakes!
> > > http://ads.osdn.com/?ad_ids93&alloc_id281&opclick
> > > _______________________________________________
> > > saxon-help mailing list
> > > saxon-help@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/saxon-help
> > >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by Oracle Space Sweepstakes
> > Want to be the first software developer in space?
> > Enter now for the Oracle Space Sweepstakes!
> > http://ads.osdn.com/?ad_ids93&alloc_id281&op=ick
> > _______________________________________________
> > saxon-help mailing list
> > saxon-help@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/saxon-help
> >
>
> -------------------------------------------------------
> This SF.Net email is sponsored by Oracle Space Sweepstakes
> Want to be the first software developer in space?
> Enter now for the Oracle Space Sweepstakes!
> http://ads.osdn.com/?ad_ids93&alloc_id281&opclick
> _______________________________________________
> saxon-help mailing list
> saxon-help@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/saxon-help
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic