|  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
 | | 
 
 
 
 
 
 
 
 | |  |  |  |  |  |  I'm suddenly getting segfaults with Xerces-C 2.3.0;
        why might this be? |  |  |  |  |  | 
 |  |  | The introduction of pluggable memory management into
        Xerces-C, one of the main features of 2.3.0, means that
        application writers have to be more conscious about
        destructors being invoked implicitly after a call to
        XMLPlatformUtils::Terminate().  For example, the
        following code is guaranteed to produce a segmentation
        fault under Xerces-C 2.3.0, while it happened to work
        under previous versions (in fact, this was how our
        SAXPrint sample was formerly written;
        try-catch blocks removed for brevity):
       |  |  |  |  |  | 
void myParsingFunction()
{
    XMLPlatformUtils::Initialize();
    SAXParser parser;
    //parser.various method calls
    XMLPlatformUtils::Terminate();
} // seg fault here!
 |  |  |  |  |  | 
The reason this will produce a segmentation fault is
        that any dynamic memory the SAXParser (or any other of
        Xerces's parsers) needs to allocate is now allocated
        by default by a static object owned by XMLPlatformUtils.
        When the XMLPlatformUtils::Terminate() call is made, this
        object is destroyed--and, consequently, so are all the
        objects that it directly created.  This includes all the
        objects dynamically allocated by the SAXParser.  When the
        parser object goes out of scope, its destructor is
        invoked, and this attempts to destroy all the objects
        that it created--which have of course just been destroyed
        by the static MemoryManager in XMLPlatformUtils.
       
        To avoid this, one must either explicitly scope the
        parser object inside calls to
        XMLPlatformUtils::Initialize() and
        XMLPlatformUtils::Terminate(), or dynamically allocate
        the parser object and destroy it explicitly before the
        call to XMLPlatformUtils::Terminate() is made.
       Another way of producing segmentation faults--that again, 
      unfortunately, was employed by some of our
      samples--is to have calls to XMLPlatformUtils::Terminate()
      in a catch block that catches any of Xerces's exceptions.
      Since the destructor of the exception will implicitly be
      invoked upon exit from the catch block, and since some of
      the exceptions' destructors call on Xerces's
      default memory manager to destroy dynamically-allocated
      objects, their destruction will provoke a segmentation
      fault even if a return statement is placed in the catch
      block since the default memory manager will no longer exist.  
      This practice is now avoided in all our samples.
       | 
 
 | |  |  |  |  |  |  Is Xerces-C++ thread-safe? |  |  |  |  |  | 
 |  |  | This is not a question that has a simple yes/no answer. Here are the
        rules for using Xerces-C++ in a multi-threaded environment: Within an address space, an instance of the parser may be used without
        restriction from a single thread, or an instance of the parser can be accessed
        from multiple threads, provided the application guarantees that only one thread
        has entered a method of the parser at any one time. When two or more parser instances exist in a process, the instances can
        be used concurrently, without external synchronization. That is, in an
        application containing two parsers and two threads, one parser can be running
        within the first thread concurrently with the second parser running within the
        second thread. The same rules apply to Xerces-C++ DOM documents. Multiple document
        instances may be concurrently accessed from different threads, but any given
        document instance can only be accessed by one thread at a time. DOMStrings allow multiple concurrent readers. All DOMString const
        methods are thread safe, and can be concurrently entered by multiple threads.
        Non-const DOMString methods, such as appendData(), are not thread safe and the application must guarantee that no other
        methods (including const methods) are executed concurrently with them. The application also needs to guarantee that only one thread has entered either the
        method XMLPlatformUtils::Initialize() or the method XMLPlatformUtils::Terminate() at any
        one time. | 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 | |  |  |  |  |  |  What character encoding should I use when creating XML documents? |  |  |  |  |  | 
 |  |  | The best choice in most cases is either utf-8 or utf-16. Advantages of
        these encodings include: 
        The best portability. These encodings are more widely supported by
          XML processors than any others, meaning that your documents will have the best
          possible chance of being read correctly, no matter where they end up.Full international character support. Both utf-8 and utf-16 cover the
          full Unicode character set, which includes all of the characters from all major
          national, international and industry character sets.Efficient. utf-8 has the smaller storage requirements for documents
          that are primarily composed of characters from the Latin alphabet. utf-16 is
          more efficient for encoding Asian languages. But both encodings cover all
          languages without loss. The only drawback of utf-8 or utf-16 is that they are not the native
        text file format for most systems, meaning that common text file editors and
        viewers can not be directly used. A second choice of encoding would be any of the others listed in the
        table above. This works best when the xml encoding is the same as the default
        system encoding on the machine where the XML document is being prepared,
        because the document will then display correctly as a plain text file. For UNIX
        systems in countries speaking Western European languages, the encoding will
        usually be iso-8859-1. The versions of Xerces distributed by IBM, both C and Java (known
        respectively as XML4C and XML4J), include all of the encodings listed in the
        above table, on all platforms. A word of caution for Windows users: The default character set on
        Windows systems is windows-1252, not iso-8859-1. While Xerces-C++ does
        recognize this Windows encoding, it is a poor choice for portable XML data
        because it is not widely recognized by other XML processing tools. If you are
        using a Windows-based editing tool to generate XML, check which character set
        it generates, and make sure that the resulting XML specifies the correct name
        in the encoding="..."declaration. | 
 
 |  |  |  | Yes, Xerces-C++ supports EBCDIC with the ibm1140, ibm037 and ibm1047 encodings.
        When creating EBCDIC encoded XML data, the preferred encoding is ibm1140. The ibm037 encoding,
        and its alternate name, ebcdic-cp-us, is almost the same as ibm1140, but
        it lacks the Euro symbol. These three encodings, ibm1140, ibm037 and ibm1047, are available on both
        Xerces-C and IBM XML4C, on all platforms. On IBM System 390, XML4C also supports three alternative forms,
        ibm037-s390, ibm1140-s390, and ibm1047-s390. These are similar to the base ibm037, ibm1140, and ibm1047
        encodings, but with alternate mappings of the EBCDIC new-line character, which
        allows them to appear as normal text files on System 390. These encodings are
        not supported on other platforms, and should not be used for portable data. XML4C on System 390 and AS/400 also provides additional EBCDIC
        encodings, including those for the character sets of different countries. The
        exact set supported will be platform dependent, and these encodings are not
        recommended for portable XML data. | 
 
 
 | |  |  |  |  |  |  How do I transcode to/from something besides the local code page? |  |  |  |  |  | 
 |  |  | XMLString::transcode() will transcode from XMLCh to the local code page, and
         other APIs which take a char* assume that the source text is in the local
         code page. If this is not true, you must transcode the text yourself. You
         can do this using local transcoding support on your OS, such as Iconv on
         Unix or IBM's ICU package. However, if your transcoding needs are simple,
         you can achieve some better portability by using the Xerces-C++ parser's
         transcoder wrappers. You get a transcoder like this:
        
         
            Call XMLPlatformUtils::fgTransServer->MakeNewTranscoderFor() and provide
            the name of the encoding you wish to create a transcoder for. This will
            return a transcoder to you, which you own and must delete when you are
            through with it.
           NOTE: You must provide a maximum block size that you will pass to the transcoder
           at one time, and you must pass blocks of characters of this count or smaller when
           you do your transcoding. The reason for this is that this is really an
           internal API and is used by the parser itself to do transcoding. The parser
           always does transcoding in known block sizes, and this allows transcoders to
           be much more efficient for internal use since it knows the max size it will
           ever have to deal with and can set itself up for that internally. In
           general, you should stick to block sizes in the 4 to 64K range.
         
            The returned transcoder is something derived from XMLTranscoder, so they
            are all returned to you via that interface.
         
            This object is really just a wrapper around the underlying transcoding
            system actually in use by your version of Xerces, and does whatever is
            necessary to handle differences between the XMLCh representation and the
            representation used by that underlying transcoding system.
         
            The transcoder object has two primary APIs, transcodeFrom() and
            transcodeTo(). These transcode between the XMLCh format and the encoding you
            indicated.
         
            These APIs will transcode as much of the source data as will fit into the
            outgoing buffer you provide. They will tell you how much of the source they
            ate and how much of the target they filled. You can use this information to
            continue the process until all source is consumed.
         
            char* data is always dealt with in terms of bytes, and XMLCh data is
            always dealt with in terms of characters. Don't mix up which you are dealing
            with or you will not get the correct results, since many encodings don't
            have a one to one relationship of characters to bytes.
         
            When transcoding from XMLCh to the target encoding, the transcodeTo()
            method provides an 'unrepresentable flag' parameter, which tells the
            transcoder how to deal with an XMLCh code point that cannot be converted
            legally to the target encoding, which can easily happen since XMLCh is
            Unicode and can represent thousands of code points. The options are to use a
            default replacement character (which the underlying transcoding service will
            choose, and which is guaranteed to be legal for the target encoding), or to
            throw an exception.
          Here is an example: |  |  |  |  |  | 
// create an XMLTranscoder that is able to transcode between Unicode and Big5
// ASSUMPTION: assumes your underlying transcoding utility supports this encoding Big5
XMLTranscoder* t = 
    XMLPlatformUtils::fgTransService->makeNewTranscoderFor("Big5", failReason, 16*1024, MemoryManager);
// source string is in Unicode, wanna to transcode to Big5
t->transcodeTo(source_unicode, length, result_Big5, length, charsEaten, XMLTranscoder::UnRep_Throw );
// source string in Big5, wanna to transcode to Unicode
t->transcodeFrom(source_Big5, length, result_unicode, length, bytesEaten, (unsigned char*)charSz);
 |  |  |  |  |  | 
 | 
 
 
 
 | |  |  |  |  |  |  Why does the parser still try to locate the DTD even validation is turned off
       and how to ignore external DTD reference? |  |  |  |  |  | 
 |  |  | When DTD is referenced, the parser will try to read it, because DTDs can
         provide a lot more information than just validation. It defines entities and
         notations, external unparsed entities, default attributes, character
         entities, etc... So it will always try to read it if present, even if
         validation is turned off.
       To ignore the DTD, with Xerces-C++ 2.7.0 or up, you can call
         setLoadExternalDTD(false)(orsetFeature(XMLUni::fgXercesLoadExternalDTD, false)to disable the loading of external DTD.   The parser will then ignore
         any external DTD completely if the validationScheme is set to Val_Never. Note: This flag is ignored if the validationScheme is set to Val_Always or Val_Auto.
       To ignore the DTD in earlier version of Xerces-C++, the
         only way to get around this is to install an EntityResolver
         (see the Redirect sample for an example of how this is done), and reset the
         DTD file to "".
       | 
 
 
 
 
 
 | 
 |