Bug 9063 - [XQ31ReqUC] Override parts of a module
Summary: [XQ31ReqUC] Override parts of a module
Status: NEW
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Requirements for Future Versions (show other bugs)
Version: Working drafts
Hardware: PC Linux
: P2 normal
Target Milestone: ---
Assignee: Jim Melton
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
Depends on:
Reported: 2010-02-18 15:44 UTC by Jonathan Robie
Modified: 2014-05-20 16:47 UTC (History)
5 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Jonathan Robie 2010-02-18 15:44:48 UTC
For future versions of XQuery, we should consider adding the ability to import a module and selectively replace a part of it.
Comment 1 John Snelson 2010-03-24 14:06:01 UTC
There's a danger that adding something like this could destroy the ability to independently compile modules. Can you give an idea of scope and motivating use cases?
Comment 2 Michael Kay 2010-03-24 14:18:07 UTC
Motivating use cases are fairly clear I think: we're all familiar (from using object oriented languages and from XSLT experience) of how much can be achieved in terms of software reuse if you can use most of the functionality of an existing system while being able to change parts of its behaviour.

I think that concerns about separate compilation could be assuaged by (a) requiring functions that are overridable to be declared as such ("non-final"), and (b) requiring the overriding function to have a compatible type signature. (Both features that are sadly missing from XSLT).
Comment 3 Adam Retter 2013-02-06 09:39:40 UTC
Being able to independently compile XQuery modules is something that is incredibly useful in XQuery as it allows you to create systems that operate on Modules for example EXQuery's RestXQ and eXist-db's SOAP Server, both of these allow translation to/from XQuery function calls from a host system or language.

If the use-case is that being able to override aspects of a module helps re-use of code through composition, is there not an argument that the granularity of the users modules is not fine enough. i.e. they could just break a module into two modules.

I am not opposed to the capability or idea of overriding aspects of modules, as long as we can maintain the capability to independently compile modules somehow.
Comment 4 Jonathan Robie 2014-05-20 16:47:14 UTC
Assigning to future requirements per Working Group decision (https://lists.w3.org/Archives/Member/w3c-xsl-query/2012Oct/0087.html).