On 8 Jan 2014, at 13:44, David Lee <[email protected]> wrote: > ---------- > As it is unless he understands the effect the group by clause can have (this > is the same group by clause that Dr Kay said he was raising a specification > bug about yesterday) he is going to be baffled as to why he is getting an > error telling him he has duplicate attribute nodes because he doesn't think > he's coded any.
The bug I raised isn't against the group by clause. It's against the use of the terms "initial clause" and "intermediate clause" with two subtly different meanings. Most people will get the correct meaning from the context, but it could certainly be made clearer. > > Brought up to another level … I think this is generally true. > If a person does something that tells a system to do something very different > than what the person thought was being asked, > And especially if the “error” is far enough out of context then error > messages can be very confusing. > > If the computer had enough context, and perhaps AI and ESP and could deduce > “OH you thought you were doing THIS but you did THAT instead and I didn’t > like that” it could produce better messaging. > > It’s a noble but tough problem … Its hard enough for computers to reliably > report on things that go wrong, > To ask them to diagnose what you thought you were doing that caused it to go > wrong is asking a lot. > Someday maybe they will be able to do that. > In the meantime us computer users have to struggle with a literally mindless > machine as best we can. > Yes. There is of course a lot that can be done to improve error messages. Sometimes implementors don't go to enough trouble to think about the possible causes of an error and the opportunities for tailoring messages. For example, if a schema requires the next element to be one of (A, B, or C), and you supply something with the right local name to match B but with a different namespace, then rather than giving the baffling message "Found B, expected A, B, or C", it's quite possible to say "Element B is in namespace foo, it should be in namespace bar". Very often this happens because the person composing the error message never actually uses the product themself, and therefore fails to realise how much could be done to make users lives easier. A very difficult thing when designing error messages is to assess how well the reader understands the specification, in two areas: (a) knowing the technical terminology, and (b) knowing what is supposed to happen. In this case the main problem is (b); the user expects an attribute node to be atomized, when the specification says that it isn't atomized, and this misunderstanding of the spec is the root cause of the error that manifests itself as adding duplicate attributes to an element. It would certainly be possible in principle (though not easy) to detect that the duplicate attributes result from evaluation of an embedded expression, and to add something like "Two attributes with the same name are being added to the XYZ element. Perhaps the attribute node should be atomized by calling the data() function?". However, when the implementor's guess is wrong, such messages can be even more misleading than the original. (Doing a deeper analysis that traces the root cause to being something to do with grouping is probably way too hard and too speculative.) The only real way of improving usability is to design a language which avoids surprises, even when users don't read the spec. This particular feature of XQuery (the fact that embedded expressions aren't atomized) is certainly one that catches users out quite often. It's too late to change it of course, and even then it's not clear what a better design would look like. In XSLT 3.0 we have introduced a similar construct (content templates) and decided that these should always be atomized, which we can do because we have the <xsl:copy-of> instruction for the alternate behaviour. So at least we're learning from mistakes. Michael Kay Saxonica
_______________________________________________ [email protected] http://x-query.com/mailman/listinfo/talk
