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:

  <x a='b'/>/@a

…will be serialized as…


It would probably have been more consistent to create output that can
always be reused, and that always contains the datatype:

  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,

[1] https://github.com/BaseXdb/basex/issues/1484

Reply via email to