Hi there,
To begin with: I forgot to mention that you can change the serialization method by launching the command "set serializer method=adaptive" in the command input text field on top of the BaseX window.
I agree this is not very comfortable, so I have now added a new interaction component for changing all serialization parameters in the GUI. I have decided to move the input components to the Preferences dialog (Ctrl-Shift-P, Visualization panel), as I’d like to keep the main interface clean. If more people ask for it, I might add a dropdown menu for the serialization method on top of the Result View, let’s see.
The new component for adjusting the serialization parameters is also available now in the Export Database dialog. A new stable snapshot is available [1], and the next minor release will be available around end of August.
Looking forward to your feedback, Christian
[1] http://files.basex.org/releases/latest/
On Fri, Aug 11, 2017 at 12:40 AM, Christian Grün christian.gruen@gmail.com wrote:
Hi Joe,
Have you considered adding a preference or toggle for selecting the default serialization method used in the GUI's results?
Sounds like an enticing idea! Something similar is embedded in our Database Export dialog (see menü items 'Database', 'Export…'). I haven’t touched it for years, and it could surely be revised as well. I will definitely think about adding something like this in to our Result View [1].
From my perspective in teaching XQuery, showing an xs:string item in quotes (and integers sans quotes) helps reinforce the concept of data types.
This is a good thought indeed.
Besides string handling, though, are there other aspects of "adaptive" that you dislike compared to the default "basex" method?
I would say that both methods (now) serve different purposes:
• Our 'basex' method was included because BaseX is used in many different contexts, and we were looking for a single serialization method that can be used for as many use cases as possible at the same time. If BaseX is used on command-line, it can be convenient if the textual output (usually XML, strings, numbers) can directly be passed on to other commands, or saved in text files. If the GUI is used, text from the result view can be copied and pasted to other tools (such as CSV output, which can be pasted in Excel, etc.).
• The 'adaptive' simplifies the recycling of results in other XQuery expressions. I agree it also helps users to understand the differences between data types. I find it a bit confusing, however, that some items will be output with a constructor function, whereas other will simply be output as strings. Some examples:
1, xs:double(1), 'a"b', xs:anyURI('a"b'), xs:QName('xml:x'), <x a='b'/>/@a
…will be serialized as…
1 1 "a""b" xs:anyURI("a""b") Q{http://www.w3.org/XML/1998/namespace%7Dx a="b"
It would probably have been more consistent to create output that can always be reused, and that always contains the datatype:
xs:integer(1) xs:double(1) xs:string("a""b") xs:anyURI("a""b") xs:QName("xml:x"), attribute a { "b" }
Well, maybe the type could have been omitted for xs:integer and xs:string, but as constructors are added for many types, I believe that any ambiguities should have been avoided.
There are surely many things that would need to be considered (for example, a namespace of a prefix might not be declared; anonymous functions could only be re-used if the full function body was serialized as well; etc).
Just my two cents, Christian