From: Dan M. <dan...@gm...> - 2010-06-04 14:04:21
|
> 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. :-)))))) On Thu, Jun 3, 2010 at 11:26 PM, Thomas White <tho...@gm...> wrote: > 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 > > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > Exist-development mailing list > Exi...@li... > https://lists.sourceforge.net/lists/listinfo/exist-development > > -- Dan McCreary Semantic Solutions Architect office: (952) 931-9198 cell: (612) 986-1552 |