[XERCESC-2197] Key Identity Constraint error reporting

• Type: Improvement
• Status: Open
• Priority: Major
• Resolution: Unresolved
• Fix Version/s: 4.0.0
• Component/s: Validating Parser (XML Schema)
• Assignee: Unassigned
• Reporter: Stefan de Konink
• Created: 14/May/20 21:57
• Updated: 06/Oct/22 13:42

Description

The current Java version of Xerces has a significant better error reporting on Identity Constraints, if compared with the C++ version. The primary issue is that the the C++ version is only reporting the name of the element the key identity constraint has been defined, the secondary issue is that the line number reported is of the element closing the tag. A properly failing document will therefore show oceans of duplicated lines in the output, while in fact they are different elements tested, in different parts of the document.

 

As example the following error is presented:

Error at file /tmp/cxx.xml, line 5009571, char 24
Message: identity constraint key for element 'ServiceFrame' not found

The expected error would be:

Error at file /tmp/cxx.xml, line 1495133, char 51
Key 'ToPointRef' with value 'CXX-ALL:RoutePoint:78210040' not found for identity constraint of element 'ServiceFrame'.

 

Since the above is quite a difference I started to fiddle with GDB a bit:

 

302 {
303 FieldValueMap& valueMap = iter.nextElement();
304
305 if (!keyValueStore->contains(&valueMap) && fDoReportError) {
306
307 fScanner->getValidator()->emitError(XMLValid::IC_KeyNotFound,
308 fIdentityConstraint->getElementName());
309 }
310 }
311 }

 

 

 

p fIdentityConstraint.fIdentityConstraintName
$34 = (XMLCh *) 0x590070 u"ToPointRef"
 
p fIdentityConstraint.fSelector.fXPath.fExpression
$40 = (XMLCh *) 0x590390 u".//netex:ToPointRef"
 
p fIdentityConstraint.fFields.fElemList[0].fXPath.fExpression
$32 = (XMLCh *) 0x590930 u"@ref"
 
p keyValueStore.fIdentityConstraint.fIdentityConstraintName
$70 = (XMLCh *) 0x57cf10 u"ScheduledStopPointId"
 
p *valueMap.fValues.fElemList
$41 = 0x8ce9d90 u"CXX-ALL:RoutePoint:78210040"
p fIdentityConstraint->getElementName()
$77 = (XMLCh *) 0x5902f0 u"ServiceFrame"

 

So I would state that making this error on par with Java is quite trivial. The only thing I did not find yet how to retrieve the line number for the element that is currently being searched for. Would be nice to get a hand in that direction for crafting a decent patch!