Re: [Exist-development] How 'at-relative' extention of the import clause that will facilitate module sharing

[James F. <jam...@ex...>]

Helle Joe,

a few ruminations on your last 'at-relative' post:

* adding at-relative is a change to xquery e.g. we would no longer be
providing XQuery v1.0 and would probably have to give an exist specific
version ... in reality I doubt there are any real backwards/forward compat
issues but once you start proposing changing foundations of xquery this can
lead to worst things ... probably cleaner to provide an exist option
defining the default behavior of 'at' (which in the xquery spec is a bit
ambiguous and gives us wiggle room to impart lots of different potentially
desired behavior) instead of adding to the language. I know others have
extended xquery in this fashion (ML, 28msec) but unsure of how safe it is to
not have xquery version "1.0"; at the top of my xquery files for now into
the future.

* generating modules which themselves are interdependent on other modules is
creating a dependency graph which will cause probs in any programming
language; I know we want to treat xquery as a programming language but
sometimes its limitations should serve as a warning ... also I really don't
see your problem as something that needs to be solved by eXist e.g.
clever source control/CM can mitigate most of the issues on deployment

* 3 levels of importing can be a sign of something bad ... to take an
analogy with class inheritance most humans stop grokking things at 2 levels
 ... I think its a good goal to make library modules that are standalone if
possible and can be understood without having to 'snake' down a complicated
set of deps ... better yet if they try to standardize (expath, exquery, etc)

* arguably an xquery developer shouldn't have to worry about performance
implications of importing unused libraries, we should strive to solve this
at a lower level

* there are ways to achieve upgrade without the need for dynamic library
loading or some discontinuity in the service being provided (e.g. the use of
clusters, etc) ... though in general upgrading is a tricky scenario
irregardless of language and especially hot upgrade ... 'at-relative' may
solve some of your short term issues but I think we need to think a bit
deeper about this scenario

* OO is a great approach for getting teams of people working together and
generating progress with apparently a lot less communication of
design/intention, etc  ... functional languages like xquery are not as easy;
you may have to discover different ways of scaling up the development
process then trying to bolt on expectations set using other approaches.

* unless I am missing something, cant you dynamically load a library using
an evil eval function today ?

lastly, xquery provides a pretty poor reuse mechanism in the form of import
... its always had probs and as I see from latest draft of v1.1
http://www.w3.org/TR/xquery-11/#id-module-import there is no plans to
enhance it; perhaps you can suggest this to the xquery WG to consider for
v1.1 ?

James Fuller