[xsd-users] Returning data by criteria

[Boris Kolpackov]

Hi Bidski,

In the future please keep your replies CC'ed to the xsd-users mailing
list as discussed in the posting guidelines:

http://www.codesynthesis.com/support/posting-guidelines.xhtml


Bidski <bidski at bigpond.net.au> writes:

> Hi,
>
> Thank you for the reply Boris.
>
> I recompiled Xerces-C++ and my project making sure that optimizations 
> were turned (set to Full Optimization) and that has decreased the loading 
> time to about 3 secs.
>
> I added the following lines to try and per-load my schema but I got some  
> weird errors (seemingly unrelated and to do with other parts of the 
> program, but they disappear upon removal of the following code)
>
>                ::std::auto_ptr<::xercesc::SAX2XMLReader> parser  
> (::xercesc::XMLReaderFactory::createXMLReader ()); // errors are 
> generated on this line
>
>      	parser->setFeature (::xercesc::XMLUni::fgSAX2CoreNameSpaces, true);
>      	parser->setFeature (::xercesc::XMLUni::fgSAX2CoreNameSpacePrefixes, 
> true);
>      	parser->setFeature  
> (::xercesc::XMLUni::fgXercesValidationErrorAsFatal, true);
>
>      	parser->setFeature (::xercesc::XMLUni::fgSAX2CoreValidation, true);
>      	parser->setFeature (::xercesc::XMLUni::fgXercesSchema, true);
>      	parser->setFeature (::xercesc::XMLUni::fgXercesSchemaFullChecking,  
> false);
>
> 	wchar_t tmp[MAX_PATH];
>      	swprintf_s(tmp, MAX_PATH, _T("%sData\\Inventory.xsd"),  
> theApp.szAppDirectory);
>      	parser->loadGrammar (tmp, ::xercesc::Grammar::SchemaGrammarType,  
> true);
>      	parser->setFeature  
> (::xercesc::XMLUni::fgXercesUseCachedGrammarInParse, true);
>
> Am I missing something here?

I don't see anything wrong with the above line. You may want to double
check that you have included all the necessary headers (you can copy
them from the performance example).


> I am planning to add other documents to this part of the program once I 
> am satisfied with the operation of this part. These will be smaller 
> documents. The validation is doing some form of type-checking on my xml 
> document isnt it? If this is the case then I would prefer not to turn it 
> off. As I intend to use this as a database, extra type checking is always 
> a good thing in my opinion.

Schema validation makes sure that your documents conform to the constraints
defined in XML Schema.


> I am yet to try expat, would like to exhaust all possible avenues within  
> xerces before i try something new.
>
> During recompilation of the xerces library under visual studio 2010 I  
> encountered a load of warnings that I would like to check with you.

You can ignore all of them, they are harmless.

Boris


[The rest of the email foolows for context].

> First off, within XSValueTest there were some lines like these
>
> #if SIZEOF_LONG == 8
>    XSValue::XSValue_Data act_v_ran64_v_1; act_v_ran64_v_1.fValue.f_long = 
> (long)+9223372036854775807;
>    XSValue::XSValue_Data act_v_ran64_v_2; act_v_ran64_v_2.fValue.f_long = 
> (long)-9223372036854775808;
> #endif
>    XSValue::XSValue_Data act_v_ran32_v_1; act_v_ran32_v_1.fValue.f_long = 
> (long)+2147483647;
>    XSValue::XSValue_Data act_v_ran32_v_2; act_v_ran32_v_2.fValue.f_long = 
> (long)-2147483648;
>
> The compiler was giving warnings about the unary minus operator being 
> used on a unsigned type ((long)-2147483648). I changed these lines to the 
> following
>
> #if SIZEOF_LONG == 8
>    XSValue::XSValue_Data act_v_ran64_v_1; act_v_ran64_v_1.fValue.f_long = 
> _I64_MAX;
>    XSValue::XSValue_Data act_v_ran64_v_2; act_v_ran64_v_2.fValue.f_long = 
> _I64_MIN;
> #endif
>    XSValue::XSValue_Data act_v_ran32_v_1; act_v_ran32_v_1.fValue.f_long = 
> LONG_MAX;
>    XSValue::XSValue_Data act_v_ran32_v_2; act_v_ran32_v_2.fValue.f_long = 
> LONG_MIN;
>
> The values of LONG_MAX/MIN and _I64_MAX are still the same as the 
> hard-coded values originally there.
>
> The other warning was about " 'this' : used in base member initializer 
> list " after a little research on the matter it looked as though the 
> behaviour would be ok as long as the 'this' pointer wasnt derefenced 
> until after all construction had been completed. I added a
>
>    #pragma warning(disable:4355)
>
> to disable that warning. Here is an example of this warning
>
> DOMDocumentImpl::DOMDocumentImpl(DOMImplementation* domImpl, 
> MemoryManager* const manager)
>    : fNode(this),                                // These two lines
>      fParent(this),                              // generate this warning
>      fNodeIDMap(0),
>      fInputEncoding(0),
>      fXmlEncoding(0),
>      fXmlStandalone(false),
>      fXmlVersion(0),
>      fDocumentURI(0),
>      fDOMConfiguration(0),
>      fUserDataTableKeys(17, manager),
>      fUserDataTable(0),
>      fCurrentBlock(0),
>      fFreePtr(0),
>      fFreeBytesRemaining(0),
>      fHeapAllocSize(kInitialHeapAllocSize),
>      fRecycleNodePtr(0),
>      fRecycleBufferPtr(0),
>      fNodeListPool(0),
>      fDocType(0),
>      fDocElement(0),
>      fNameTableSize(257),
>      fNormalizer(0),
>      fRanges(0),
>      fNodeIterators(0),
>      fMemoryManager(manager),
>      fDOMImplementation(domImpl),
>      fChanges(0),
>      errorChecking(true)
> {
>    fNameTable = (DOMStringPoolEntry**)allocate (
>      sizeof (DOMStringPoolEntry*) * fNameTableSize);
>    for (XMLSize_t i = 0; i < fNameTableSize; i++)
>      fNameTable[i] = 0;
> }
>
> Are those actions in line with what should be happening within the program?
>