Saxonica 1.1 XSD Validation reporting errors, whereas Xml Spy 2016 does not

Added by Jason Callister almost 8 years ago

Using the following properties: SetProperty(http://saxon.sf.net/feature/validation-warnings, SaxonicaConstants.TRUE); SetProperty(http://saxon.sf.net/feature/multipleSchemaImports, SaxonicaConstants.TRUE);

It appears that we are getting 'over-assertions', where there is no data to be checked. The below XML doesn't include the field that the error is reporting on. This passes in XML Spy.

Error(multiple of these)- Element AccountHolder does not satisfy assertion if (/crs:CRS_OECD/crs:CrsBody/crs:ReportingGroup/crs:AccountReport/crs:AccountHolder/crs:AcctHolderType eq 'CRS102' or /crs:CRS_OECD/crs:CrsBody/crs:ReportingGroup/crs:AccountReport/crs:AccountHolder/crs:AcctHolderType eq 'CRS103') then (exists(/crs:CRS_OECD/crs:CrsBody/crs:ReportingGroup/crs:AccountReport/crs:AccountHolder/crs:Organisation/crs:ResCountryCode)) else true()

h2. XML




	
		IM
		IM
		CRS
		File1
		2016-12-31
		2016-11-17T09:30:47Z
	
	
		
			IM
			Big Bank
			 
				IM
				1 Smith Street
			 
			
				OECD1
				C000000A01.123456.1
			
		
		
			
				
					OECD1
					C000000A01.123456.2
				
				1
				
					
						ES
						12345
						
							Peter
							Smith
						
						 
							ES
							1 Highway 11
						 
					
				
				1234.99
			
			
				
					OECD1
					C000000A01.123456.3
				
				2
				
					
						DE
						ABC12345
						
							Paul
							Simons
						
						 
							DE
							2 Highway 11
						 
					
				
				99100.99
				
					CRS501
					12000.11

Replies (1)

RE: Saxonica 1.1 XSD Validation reporting errors, whereas Xml Spy 2016 does not - Added by Michael Kay almost 8 years ago

Firstly, there are warnings being output:

XPDY0050: The root of the tree containing the context item is not a document node

Unfortunately it's not very explicit what these relate to. What they actually mean is that there's a problem with the XPath expression @/crs:CRS_OECD/crs:CrsBody/....@ because "/" selects a document node at the root of the tree, but the tree to which assertions are applied is rooted at the element being validated. Nodes outside the subtree rooted at this element are not available to assertions - this is a fundamental principle of the design, to ensure that the validity of an element does not change if the element is moved or copied to a different context.

This is actually a dynamic error in evaluation of the XPath expression, but the spec for XSD assertions says that a dynamic error while evaluating an assertion is treated as if the assertion were false: which is why Saxon goes on to report that the element does not satisfy the assertion.

I don't understand the semantics of these validation rules, but I suspect the assertion should be written as:

@if (crs:AcctHolderType eq 'CRS102' or crs:AcctHolderType eq 'CRS103') then (exists(crs:Organisation/crs:ResCountryCode)) else true() @ which could be simplified to

@not(crs:AcctHolderType = ('CRS102', 'CRS103)) or exists(crs:Organisation/crs:ResCountryCode)@

(1-1/1)

Please register to reply

Project

Profile

Help

Saxon