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

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,

[1] http://files.basex.org/releases/latest/

On Fri, Aug 11, 2017 at 12:40 AM, Christian Grün
<christian.gr...@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}x
>   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
> [1] https://github.com/BaseXdb/basex/issues/1484

Reply via email to