Feature #4512
closed
Fix Committed on Branch:
10
Fixed in Maintenance Release:
Description
In response to bug #4507, I am looking at the possibility of implementing streamable XSD assertions.
The general approach is as follows:
-
Add an attribute saxon:streamable=true|false to xsd:assert. If true, then at schema compile time we assess the streamability of the XPath expression. If it's motionless or consuming, proceed as follows. Otherwise, issue a warning and ignore the request for streaming.
-
If the assertion is motionless (looks at attributes only) then evaluate it while positioned at the start tag. We can do this whether or not we are currently building a tree for other assertions. This should be pretty straightforward.
-
If the assertion is consuming, and we are not already building a tree for some ancestor element, then open a Watch with the WatchManager to evaluate the assertion. This is rather more complex, but it should be possible to do it by reusing existing machinery.
Handling motionless assertions is quite straightforward, with one caveat: it may be a bit tricky to ensure that the XPath expression does not attempt to access attributes of ancestor elements.
Handling consuming assertions is proving a bit more tricky, because of the complex structure of the validation pipeline.
The problem is basically that the ValidationStack sends the startElement() event down the pipeline (specifically, to the validator associated with its parent element), and this action determines the governing type for the child element. Only when we know the governing type do we know if there are any consuming assertions for the type, but by then it's too late to register a trigger with the WatchManager because the WatchManager has already processed the startElement() event.
I think the answer might be to have a second WatchManager that is only concerned with handling of assertions. The logic for this can go in the AssertionTreeBuilder class which is currently responsible for starting and stopping the building of temporary trees for non-streamed assertion evaluation.
Note that if a tree is already under construction for a part of the document in which a consuming assertion appears, then it's better to evaluate the assertion in non-streamed mode against that tree rather than to set up a streamed evaluation in parallel.
- Status changed from New to In Progress
I now have this largely working. I have adapted the W3C tests for assertions to use streaming where possible (new tests in xsd-extra/Assert), and am currently seeing 73 passes and 5 failures. I suspect these are edge cases like assertions referring to comment nodes but I will analyze the failures individually.
- Status changed from In Progress to Resolved
- Priority changed from Low to Normal
- Applies to branch 10 added
- Fix Committed on Branch 10 added
Feature now implemented, tested, and documented.
There are some limitations / non-conformances when streaming of an assertion is requested:
-
We don't prevent access to ancestors outside the validation tree
-
Comments and PIs are visible
-
The root element of the validation tree is typed.
- % Done changed from 0 to 100
- Fixed in Maintenance Release 10.1 added
Bug fix committed in the Saxon 10.1 maintenance release.
- Status changed from Resolved to Closed
Please register to edit this issue
Also available in: Atom
PDF
.