RE: Future of XQuery and XQuery Update Faclilty

[Hans-Juergen Rennau]

Hello FLorian,

may I add a little remark? I urgently await the XQUF and simply cannot understand that your question is not asked by many voices (including mine, until today).

I think XQUF is not any more a "facility" than, say, FLOWR expressions or constructors, rather it is - would be - a central part of the language, freeing the user from the obligation to think unnaturally. When some detail in a bathroom must be fixed, we get a hammer and fix it. XQuery 1.0, however, forces to rebuild the house, making sure to incorporate a fixed bathroom. I speak from practical experience with WordML documents. If you want to modify little - but more than an attribute or element with simple content - you tend to run into very error-prone recursion code, maintaining several big typeswitch expressions in parallel, to be chosen from according to context. One might argue that such push processing is a case for  XSLT? I would not accept this as a justification for leaving the XQUF out, if only for architectural reasons: I regard XQuery not as a query language, but as a general purpose data processing language, and I see a great perspective in
 largescale OO/XQ patchworks. In this context, (a) having to pull XSLT into the boat as well and switch between X... and X... considerably enhances complexity, (b) local modification within very complex structures would be among the basic responsibilities of the XQ part. Besides Office documents, XHTML documents, SOAP headers and webservice results would be classic targets. 

So I think it is a pity that the present point of language development does not emphatically address what seems to me so important, according to project experience as well as theoretical considerations

With kind regards -
Hans-Juergen Rennau


       __________________________________ Ihr erstes Fernweh? Wo gibt es den schönsten Strand? www.yahoo.de/clever