You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@xmlbeans.apache.org by Ben Anderson <be...@gmail.com> on 2005/05/13 17:18:03 UTC
patch (sax adherence) WAS: [saxon] help deciphering stack trace
doh - forgot to mention that these line numbers correspond to 1.0.4.
Also, I noticed the same problem in 2.0 (the namespace is being set,
but not the localname).
-Ben
On 5/13/05, Ben Anderson <be...@gmail.com> wrote:
> 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 <mi...@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 <mi...@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 <mi...@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