Hi,
The time to move to new Xerces has come to our project.
Since many time has passed since our last discussions, I would like to ask some questions to see if smth. was implemented/not implemented
 
1. Did you implemented (or are planning to implememnt) the third party transcoders support
(for example, via user-defined variables)?
 
For now (let see Win32PlatformUtils.cpp) it looks like:
 
#if defined (XML_USE_ICU_TRANSCODER)
    #include <util/Transcoders/ICU/ICUTransService.hpp>
#elif defined (XML_USE_WIN32_TRANSCODER)
    #include <util/Transcoders/Win32/Win32TransService.hpp>
#else
    #error A transcoding service must be chosen
#endif
So I could not attach my transcoder w/o writting smth. like
 
#if defined (XML_USE_ICU_TRANSCODER)
    #include <util/Transcoders/ICU/ICUTransService.hpp>
#elif defined (XML_USE_WIN32_TRANSCODER)
    #include <util/Transcoders/Win32/Win32TransService.hpp>
#elif defined (XML_USE_MY_TRANSCODER)
    #include <MyTransService.hpp>                            // Need to modify original file
#else
    #error A transcoding service must be chosen
#endif
 
and later in this source:
 
XMLTransService* XMLPlatformUtils::makeTransService()
{
    //
    //  Since we are going to use the ICU service, we have to tell it where
    //  its converter files are. If the ICU_DATA environment variable is set,
    //  then its been told. Otherwise, we tell it our default value relative
    //  to our DLL.
    //
#if defined (XML_USE_ICU_TRANSCODER)
    return new ICUTransService;
#elif defined (XML_USE_WIN32_TRANSCODER)
    return new Win32TransService;
#elif defined (XML_USE_MY_TRANSCODER)
    return new MyTransService;
#else
    #error You must provide a transcoding service implementation
#endif
}
 
This is not convenient for the following reasons:
- Each time I do cvs update, I need to merge the code (to be sure my changes are not lost)
- I modify your code, so that the users cannot update to new xerces.dll .
- your code becomes depended on mine
 
It would be god, to support user defined transcoder w/o modifying the platform files.
 
 
 
2. Skip DTD if it is not presented
I need a way to ignore "CouldNotOpenDTD" error and continue parsing.
In the previous version the code was straightforward:
 
 
//---------------------------------------------------------------------
// Catches the "CouldNotOpenDTD" error
//---------------------------------------------------------------------
void MyXmlParser::error(
    const ErrorCodes::XML4CErrors code,
    const XMLCh* const errorText,
    const XMLCh* const systemId,
    const XMLCh* const publicId,
    const unsigned int lineNum,
    const unsigned int colNum )
{
    if( m_skipDtd && ( code == ErrorCodes::E_CouldNotOpenDTD ) )
    {
        return;    // ignore error
    }
 
    NonValidatingDOMParser::error(
        code,
        errorText,
        systemId,
        publicId,
        lineNum,
        colNum );
}
 
In the new version, this error  is considered to be critical and parsing abandones.
You motivated it (absolutely correct) that if dtd cannot be located the document does not conform to xml specification and cannot be proceed.
But you noted also, so that it would not be too difficult to allow ignoring such an error (as additional feature)
I have seen that many users claim about parsing xml w/o dtd (even it is in DOCTYPE declaration) (except tose cases of course, when validation is required). So why not support this,by enabling/disabling the corresponding flag? (as default, to conform xml. spec it should be disabled, but for advanced programmers, it should be possible to enable)
 
 
3. I need the following methods to be opened (as protected) in parsers\DOMParser.hpp
 
protected:
 
DOM_Node getCurrentParent();
void setCurrentParent(DOM_Node toSet);
inline DOM_Node DOMParser::getCurrentParent()
{
    return fCurrentParent;
}
inline void DOMParser::setCurrentParent(DOM_Node toSet)
{
    fCurrentParent = toSet;
}
 
Since you had opened:
DOM_Node getCurrentNode();
void setCurrentNode(DOM_Node toSet);
 
why not to open parent ?
 
 
I would appreciate you for your assistance
Peter A. Volchek
 
 
 

Reply via email to