Hi Christian,
I just gave it a try, and the new serialization preferences work like a charm.
It's pretty amazing to see a request go from idea to implementation so quickly - thank you! I think it's a nice touch that serialization options specified in a query are respected, so the preferences only affect the defaults that apply to a query - they don't override anything in a query.
Your listing of ambiguities in the adaptive method are certainly valid. The quote escaping does bother me, so it does come at a cost, I guess. I do find myself quickly switching away to JSON or text serialization to avoid some of these quirks when I don't like the look of adaptive.
And, to close the loop, I agree that the spec remains ambiguous in the area of indentation of maps and arrays, and while BaseX in no way violates the spec here, I personally would advocate for consistency in the way maps and arrays are indented and serialized across the various map- and array-aware methods. But this is a terribly minor point, and folks who want uniformity can always use another tool to pretty-print their data.
Finally, I just remembered observation that came up during the class - the BaseX GUI editor's syntax highlighting sometimes breaks down in odd places, such as the middle of a function name, e.g., in `fn:format-date()`, the `fn` and `-date` are colored black, but `format` is colored blue. I've attached a screenshot showing the phenomenon. Again, this isn't a major issue, and syntax highlighting probably can't always be perfect, but I thought I'd mention it since it came up.
Thanks again for all of your kind assistance! Joe
On Thu, Aug 10, 2017 at 11:29 PM, Christian Grün christian.gruen@gmail.com wrote:
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
