From: Thomas W. <tho...@gm...> - 2010-06-04 04:27:08
|
James, Sorry for the delayed response. On 31 May 2010 10:06, James Fuller <jam...@ex...> wrote: > 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 thing > ... 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. > I no not think there is a real problem about backwards/forward compatibility issues. Other XQuery vendors have chosen to deal with the challenges that the real life offer and they offered a solution by extending the language. What they did is "implementation is the specification" vs "design by committee" and the latter is notorious about how slow, inefficient and sometimes even driven by ulterior motives a design process could be. When we offer a good solution that proves its usefulness it will be adopted by the others quickly. To me the inability to create a library that can keep its internal structure the way vendor wants or needs and forcing modules to be always self contained is a severe limitation and major problem that discourages people to share their code. If I have a solution that is separated in a number of modules and I want to share it I need to go to the trouble and combine all modules into one file and have one version of the code for internal use and other for sharing. That is counter productive and may be that is why there are not that many XQuery libraries available out there. Your idea of changing the default behaviour of 'at' is actually what I wanted to avoid. The reason I propose 'at-relative' was to add new feature and in the same time do not break any existing code. > * generating modules which themselves are interdependent on other modules > is creating a dependency graph which will cause probs in any programming > language; > As you said "... arguably an xquery developer shouldn't have to worry about this". It is done in many other languages and it is not that complicated to be done with XQuere as well if we want to. > I know we want to treat xquery as a programming language but sometimes its > limitations should serve as a warning .. > And here is where I am going to take it personally (not really, but just to show how passionate I am about what I am doing :-). XQuery is a very powerful language that is capable of amazing things. For the last two years I made a dramatic shift from XSLT hard code purist to a XQuery enthusiast who does almost everything in XQuery (Dan I can see you smiling already!) and I produce the result may be 5 to 10 times quicker. Limitations like this do not serve any good purpose. They are there just because a quick and simple approach was needed when the XQuery spec was produced. Nothing more. May be it is height time to start treating XQuery as a real language. It is strange that I need to prove we need something that in any other language is a good practice that has proven its advantages for years. . 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 > I do not get this. If I use a library from somebody else how the source control will solve anything? It comes as a package. > * 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) > I think we a talking about completely different issues. In XQuery we do not have a *vertical *levels of inheritance - we have a * horizontal level re-usability*. Consider the case of hotel management system where for each main entity like visitor, reservation, room and report there is a team that organised their code in number of modules. The problem comes when they need to share code across teams. A Booking needs to use some functions from Visitor and Room. There is not inheritance here - we just need to organise the code in nice relevant manageable chunks for each departments and share it. Unfortunately with the current implementation the only possible way is to to have huge monolithic modules. In practice if we have a single file per team this means we can have only one person working on an area at a time. I think this is big and very important - inability to import modules relative to the importing module does hinders the team work on large projects. > * 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 > Good words but when a module is monolithic there is not other chance but to create an instance of the whole module. > * 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. > I think working in teams, collaborating and reusability of code has nothing to do with the language or the programming paradigm. It is all about providing mechanisms for assembling the pieces of code behind the scenes which is well established in OO programming and it just about to to used more in functional languages as well. XSLT is a functional language and it offers file import relative to the file that does the importing. > 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 ? > Yes I agree XQuery provides a pretty poor reuse mechanism. But we can change this and make XQuery code much more reusable. And one more thing - we do not necessary need to wait another 3 or 5 year for a committee to decide it for us :-) I hope I have convince all of you a little bit more in favour of 'at-relative' and the time when we are going to see it implemented came a little bit closer. Thomas White |