You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@xerces.apache.org by "Alberto Massari (JIRA)" <xe...@xml.apache.org> on 2005/05/18 16:27:07 UTC
[jira] Updated: (XERCESC-1419) Regular expressions in schema should allow unescaped '-'
[ http://issues.apache.org/jira/browse/XERCESC-1419?page=all ]
Alberto Massari updated XERCESC-1419:
-------------------------------------
Attachment: pattern1.xsd
pattern1.xml
Sample schema and XML document
> Regular expressions in schema should allow unescaped '-'
> --------------------------------------------------------
>
> Key: XERCESC-1419
> URL: http://issues.apache.org/jira/browse/XERCESC-1419
> Project: Xerces-C++
> Type: Bug
> Components: Validating Parser (Schema) (Xerces 1.5 or up only)
> Versions: 2.6.0
> Environment: any
> Reporter: Alberto Massari
> Attachments: pattern1.xml, pattern1.xsd
>
> As part of the errata E2-18 the character '-' has been removed from the set of characters that can be used in the character range of a regular expression pattern, requiring it to be specified as '\-'. However, a few months after, a new errata has been published, E2-67 (http://www.w3.org/2001/05/xmlschema-errata#e2-67), that reverses that decision and adds a note to resolve the ambiguity that caused E2-18.
> The Second Edition of the XMLSchema specs includes the text from E2-67.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: [MacOS X/CodeWarrior 9.5] XercesLib 2.6 problem
Posted by James Berry <jb...@apache.org>.
Hi Patrick,
This is a problem that shows up with both CodeWarrior 9 and gcc 4.0,
but not gcc 3.x. They don't like the fact that the static keyword is
used redundantly in the definition of the data members. To fix the
problem, remove the two instances of the static keyword in the .cpp
file.
This issue has been fixed in cvs.
-jdb
On May 18, 2005, at 9:14 AM, Patrick Perroud wrote:
> Hello,
>
> I have downloaded XercesLib sources from http://xml.apache.org, and
> I am now trying to compile the mach-o release target, with
> CodeWarrior 9.5, on MacOS X 10.3.9, but failed so far with the
> following issues:
> - - - - -
> Error : object
> 'xercesc_2_6::MacOSUnicodeConverter::fgMyServiceId' redefined
> MacOSUnicodeConverter.cpp line 79 static const XMLCh
> MacOSUnicodeConverter::fgMyServiceId[] = {
>
> Error : object
> 'xercesc_2_6::MacOSUnicodeConverter::fgMacLCPEncodingName' redefined
> MacOSUnicodeConverter.cpp line 84 tatic const XMLCh
> MacOSUnicodeConverter::fgMacLCPEncodingName[] =
> - - - - -
>
> So apparently there is a problem in 2.6 with the
> MacOSUnicodeConverter class, that differs from version 2.4 by
> adding this in the class definition (under "private:"):
> - - - - -
> static const XMLCh fgMyServiceId[]; // Name of the our
> unicode converter
> static const XMLCh fgMacLCPEncodingName[; // Name of the LCP
> transcoder we create
> - - - - -
>
> With the following *implementation*:
> - - - - -
> static const XMLCh MacOSUnicodeConverter::fgMyServiceId[] = {
> chLatin_M, chLatin_a, chLatin_c, chLatin_O, chLatin_S, chNull
> };
>
> static const XMLCh MacOSUnicodeConverter::fgMacLCPEncodingName[] = {
> chLatin_M, chLatin_a, chLatin_c, chLatin_O, chLatin_S,
> chLatin_L
> , chLatin_C, chLatin_P, chLatin_E, chLatin_c, chLatin_o,
> chLatin_d
> , chLatin_i, chLatin_n, chLatin_g, chNull
> }
> - - - - -
>
> I have searched for *redifinitions* in XercesLib project, but
> didn't find any - so I suppose it's a kind of function member
> signature issue, but I can't see any difference between these class
> interfaces' signature and the signature of their actual
> implementations . . .
>
> Everything else within that XercesLib 2.6 project did compile just
> fine - so that's too bad . . .
>
> Any other idea or suggestion would be welcommed, indeed.
>
> Best regards
>
> Patrick Perroud
>
>
> - - - - - - - - -
> http://p.perroud.free.fr/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
> For additional commands, e-mail: c-dev-help@xerces.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
[MacOS X/CodeWarrior 9.5] XercesLib 2.6 problem
Posted by Patrick Perroud <pa...@pperroud.com>.
Hello,
I have downloaded XercesLib sources from http://xml.apache.org, and I
am now trying to compile the mach-o release target, with CodeWarrior
9.5, on MacOS X 10.3.9, but failed so far with the following issues:
- - - - -
Error : object 'xercesc_2_6::MacOSUnicodeConverter::fgMyServiceId'
redefined
MacOSUnicodeConverter.cpp line 79 static const XMLCh
MacOSUnicodeConverter::fgMyServiceId[] = {
Error : object
'xercesc_2_6::MacOSUnicodeConverter::fgMacLCPEncodingName' redefined
MacOSUnicodeConverter.cpp line 84 tatic const XMLCh
MacOSUnicodeConverter::fgMacLCPEncodingName[] =
- - - - -
So apparently there is a problem in 2.6 with the MacOSUnicodeConverter
class, that differs from version 2.4 by adding this in the class
definition (under "private:"):
- - - - -
static const XMLCh fgMyServiceId[]; // Name of the our unicode
converter
static const XMLCh fgMacLCPEncodingName[; // Name of the LCP
transcoder we create
- - - - -
With the following *implementation*:
- - - - -
static const XMLCh MacOSUnicodeConverter::fgMyServiceId[] = {
chLatin_M, chLatin_a, chLatin_c, chLatin_O, chLatin_S, chNull
};
static const XMLCh MacOSUnicodeConverter::fgMacLCPEncodingName[] = {
chLatin_M, chLatin_a, chLatin_c, chLatin_O, chLatin_S, chLatin_L
, chLatin_C, chLatin_P, chLatin_E, chLatin_c, chLatin_o, chLatin_d
, chLatin_i, chLatin_n, chLatin_g, chNull
}
- - - - -
I have searched for *redifinitions* in XercesLib project, but didn't
find any - so I suppose it's a kind of function member signature issue,
but I can't see any difference between these class interfaces'
signature and the signature of their actual implementations . . .
Everything else within that XercesLib 2.6 project did compile just fine
- so that's too bad . . .
Any other idea or suggestion would be welcommed, indeed.
Best regards
Patrick Perroud
- - - - - - - - -
http://p.perroud.free.fr/
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org