[
https://issues.apache.org/jira/browse/XERCESC-1903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12795030#action_12795030
]
Alberto Massari commented on XERCESC-1903:
------------------------------------------
In that commit I have rewritten the way prefixes are resolved, making the
resolveQName non-virtual and implemented in the base class XMLScanner. At that
point the check done in the ElemStack was unnecessary, as it was already done
earlier.
For XQilla, it is now unnecessary to define SchemaValidatorFilter::resolveQName
altogether and should be put inside an #ifdef
As David said, both XMLScanner and ElemStack are internal classes, and we don't
try to keep them unchanged between minor revisions.
Alberto
> xerces-c-3.1.0-rc1: possible API change?
> ----------------------------------------
>
> Key: XERCESC-1903
> URL: https://issues.apache.org/jira/browse/XERCESC-1903
> Project: Xerces-C++
> Issue Type: Bug
> Affects Versions: 3.1.0
> Environment: debian
> Reporter: Jay Berkenbilt
>
> A debian user reports trouble compiling xqilla 2.2.2
> (http://xqilla.sourceforge.net) with xerces-c 3.1.0 rc1 but says that it does
> compile with 3.0.1. We exchanged a few messages, but neither one of us is
> sure whether the code in question is using an internal interface that is not
> supposed to be part of the public API or whether this is an unintentional API
> incompatibility. I'm including the text of our latest email exchange here so
> you can make a judgment call on this before the final 3.1.0 is released.
> ======================
> >> I was compiling XQilla library version 2.2.2 from
> >> http://xqilla.sourceforge.net against Xerces-C in Debian, when I noticed
> >> that the xqilla library cannot be compiled against libxerces-c-dev
> >> 3.1.0~rc1, but it can compiled against version 3.0.1 still in testing.
> >> So it seems that version 3.1 breaks API compatibility. Are you and/or
> >> upstream developers aware of this? Is this actually a bug that I should
> >> report against libxerces-c-dev or not?
> >
> > I'm not aware of any expected API changes between 3.0.1 and 3.1.0, but I
> > haven't checked with upstream. I believe the intention is not to
> > introduce API compatibilities though. Please go ahead and file a bug
> > against the debian package. Obviously any specific details you can
> > provide would be helpful. I will then forward it to upstream. Thanks
> > for bringing this to my attention!
> Hi,
> I looked now the error messages a bit more to see what was changed, and
> noticed that those API breaks are in a class definition in the subdir
> "internal". Thus I now wonder if it counts as API break that would in
> the interest of the developers. Here is the compiler error I got:
> src/schema/SchemaValidatorFilter.cpp: In member function 'virtual unsigned
> int SchemaValidatorFilter::resolveQName(const XMLCh*,
> xercesc_3_1::XMLBuffer&, short int, int&)':
> src/schema/SchemaValidatorFilter.cpp:713: error: no matching function for
> call to 'xercesc_3_1::ElemStack::mapPrefixToURI(const XMLCh [],
> xercesc_3_1::ElemStack::MapModes, bool&)'
> /usr/include/xercesc/internal/ElemStack.hpp:190: note: candidates are:
> unsigned int xercesc_3_1::ElemStack::mapPrefixToURI(const XMLCh*, bool&) const
> src/schema/SchemaValidatorFilter.cpp:729: error: no matching function for
> call to 'xercesc_3_1::ElemStack::mapPrefixToURI(XMLCh*,
> xercesc_3_1::ElemStack::MapModes, bool&)'
> /usr/include/xercesc/internal/ElemStack.hpp:190: note: candidates are:
> unsigned int xercesc_3_1::ElemStack::mapPrefixToURI(const XMLCh*, bool&) const
> --
> Tommi Vainikainen
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
