This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 5579 - Update 1.1: In-situ validation
Summary: Update 1.1: In-situ validation
Status: RESOLVED WONTFIX
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Requirements for Future Versions (show other bugs)
Version: Candidate Recommendation
Hardware: PC Windows XP
: P2 enhancement
Target Milestone: ---
Assignee: Jonathan Robie
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-03-19 22:49 UTC by Michael Kay
Modified: 2014-07-30 14:23 UTC (History)
2 users (show)

See Also:


Attachments

Description Michael Kay 2008-03-19 22:49:15 UTC
It would sometimes be useful to validate a document in-situ, that is, without having to create a copy. And indeed, XQuery Update defines such a facility in the form of the internal upd:revalidate() function. However, this functionality is not directly available to users. The only way to invoke it is to do a dummy update (for example, renaming an element to its existing name). It would seem to be useful to add some surface syntax that invokes the functionality directly: perhaps a function call, perhaps some construct such as "validate strict in place { expr }".
Comment 1 Jonathan Robie 2009-03-31 16:38:32 UTC
In updates, the validation is seen after updates are applied - when would it be seen in your proposal?

There are some systems where it is not possible to keep the identity of nodes while changing their properties, which validation does.

Would it make more sense to do this as part of scripting?

Can you say more about the use cases?
Comment 2 Michael Kay 2009-03-31 22:49:20 UTC
The first justification for the proposal is that we already provide the facility of in-situ validation, we just don't provide any sensible surface syntax for it: you invoke it, for example, by doing a rename on a node with the new name being the same as the old. Since implementations have to provide the capability, it makes sense to make it accessible to users. This is a justification based on orthogonality of design, not on specific use cases.

Clearly, as with all updates, use cases depend on the context in which updates are run: we don't provide any way of taking advantage of the fact that a rename was done without change of identity, but we assume that updates will occur in an environment where this is significant to applications. The same applies to validation. 

Comment 3 Jonathan Robie 2009-03-31 23:28:15 UTC
I don't yet understand the semantics you would propose, and how this relates to snapshot semantics.

Jonathan
Comment 4 Michael Kay 2009-04-01 08:08:52 UTC
The proposed semantics are to add an entry to the PUL whose effect is to cause upd:applyUpdates to invoke upd:revalidate on a specified node.
Comment 5 Jonathan Robie 2009-04-28 16:29:25 UTC
The WG has decided to defer this to 1.1.
Comment 6 Jonathan Robie 2014-07-30 14:23:09 UTC
The Working Group decided to close this without change.