Project

Profile

Help

Actions
Send by e-mail Copy link

Bug #3062

closed

Validation of element node ignores xsi:type attribute

Added by Petr K almost 8 years ago. Updated almost 7 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Michael Kay
Category:
Schema-Aware processing
Sprint/Milestone:
-
Start date:
2016-12-08
Due date:
% Done:

100%

Estimated time:
Legacy ID:
Applies to branch:
9.7, 9.8, trunk
Fix Committed on Branch:
9.7, 9.8, trunk
Fixed in Maintenance Release:
9.7.0.15, 9.8.0.8
Platforms:

Description

validate{ $elem } throws and exception: : Cannot validate content against an abstract type. The element declaration for $elem has an abstract type, but the $elem instance has an xsi:type attribute that designates a concrete type, which should be used as the governing type for validation.

Files

AbstractType.zip (3.32 KB) AbstractType.zip Petr K, 2016-12-08 15:12
Actions
Copy link
 #1

Updated by Michael Kay almost 8 years ago

  • Description updated (diff)
  • Category set to Schema-Aware processing
  • Assignee set to Michael Kay
  • Priority changed from High to Normal
Actions
Copy link
 #2

Updated by Michael Kay almost 8 years ago

It seems that when validation is requested at element level, an xsi:type attribute on the target of the validation request is ignored.

Note: bug #2100 changed some of the code in this area.

Actions
Copy link
 #3

Updated by Michael Kay almost 8 years ago

  • Subject changed from xq: element validation of abstract type in xsd but concrete in xml to Validation of element node ignores xsi:type attribute
  • Status changed from New to Resolved
  • Applies to branch 9.8 added
  • Fix Committed on Branch 9.7, 9.8 added

The code path also affects XSLT validation at element level (though I haven't verified the failure in this case).

Now fixed: the validation code for elements in CopyOf tests for the existence of an xsi:type attribute on the element being validated.

JUnit test added to module xqjtests/TestXQuery

QT3 test ValidateExpr/validate-as-107 added.

Actions
Copy link
 #4

Updated by O'Neil Delpratt almost 8 years ago

  • Status changed from Resolved to Closed
  • % Done changed from 0 to 100
  • Fixed in Maintenance Release 9.7.0.15 added

Bug fix applied to the Saxon 9.7.0.15 maintenance release

Actions
Copy link
 #5

Updated by O'Neil Delpratt over 7 years ago

  • Fix Committed on Branch trunk added
  • Fix Committed on Branch deleted (9.8)
Actions
Copy link
 #6

Updated by O'Neil Delpratt over 7 years ago

  • Applies to branch deleted (9.8)
Actions
Copy link
 #7

Updated by Michael Kay almost 7 years ago

  • Status changed from Closed to In Progress

Reopened: in forum post https://saxonica.plan.io/boards/3/topics/7084 a user reports getting an error when using xsl:copy-of with Saxon-HE when the target of the instruction is an element with an xsi:type attribute.

Actions
Copy link
 #8

Updated by Michael Kay almost 7 years ago

Looking again at the spec for default-validation took me off on a tangent, resulting in spec bug https://www.w3.org/Bugs/Public/show_bug.cgi?id=30211

Actions
Copy link
 #9

Updated by Michael Kay almost 7 years ago

  • Status changed from In Progress to Resolved
  • Applies to branch 9.8, trunk added
  • Fix Committed on Branch 9.8 added

I have made a further modification to the code (in CopyOf.processLeavingTail) so that the checking of the xsi:type value now occurs only if strict or lax validation is requested (and not validation=strip|skip|preserve).

Change applied on the 9.7, 9.8, and trunk branches

Actions
Copy link
 #10

Updated by O'Neil Delpratt almost 7 years ago

  • Status changed from Resolved to Closed
  • Fixed in Maintenance Release 9.8.0.8 added

Bug fix applied in the Saxon 9.8.0.8 maintenance release.

Please register to edit this issue

Actions
Send by e-mail Copy link

Also available in: Atom PDF