This would be the "simplify FLWOR expression:" returned just above the "Optimized Query" section of the info window?

I have found that helpful when using the BaseX GUI to teach. XPath in particular, but XQuery as well. I would vote to keep it, if there were to be a vote.

-- Graydon

On Mon, Apr 11, 2022 at 5:48 AM Christian Grün christian.gruen@gmail.com wrote:

Maybe we should drop the shrinked representation of the original query string from the Info View (and the command-line output) as it seems to be confusing. In most cases, it’s redundant anyway.

On Sun, Apr 10, 2022 at 8:45 PM Markus Elfring Markus.Elfring@web.de wrote:

...

...

What do you mean with space character?

I suggest to take a closer look at the differences from a display like “``["line 1 line 2 line 3"]``” in comparison to the mentioned test example. Would you find any other representation more appropriate here?

Regards, Markus

On Mon, Apr 11, 2022 at 06:06:19PM +0200, Markus Elfring scripsit:

...

This would be the "simplify FLWOR expression:" returned just above the "Optimized Query" section of the info window?

I suggest to take another look at the items in the drop-down list of the info view.

Do you find the item “Query” still relevant for further displays?

Sure!

The teaching use is to compare the Query, the Optimized Query, and the steps in Compiling.

One of the core things with any declarative language is to not argue with the optimizer, and looking at those Info items for simple things, particularly XPath, helps build a sense of what the optimizer expects.

If the Query return has been rendered on a single line, well, XML doesn't consider white space significant, and a few reminders of that do no harm.

On Mon, Apr 11, 2022 at 09:27:13PM +0200, Markus Elfring scripsit:

...

...

Do you find the item “Query” still relevant for further displays?

Sure!

The teaching use is to compare the Query, …

How much do care that the display for the item “Query” would be equivalent to the original XQuery script (including special characters like line breaks)?

Not at all.

U+000A LINE FEED is one of three control characters allowed in XML. It's inherently special, but it's also white space, and white space is not important. The query itself is not in and must not be in a presentation format where white space has semantic meaning. (Both of those are teachable moments, especially for people whose academic training involved a lot of python.)

...

If the Query return has been rendered on a single line, well, XML doesn't consider white space significant, and a few reminders of that do no harm.

I suggest to reconsider such a view also a bit more.

I've been doing mostly document-representation XML processing for twenty-odd years now. There is no business case for pretty, stable indents, or semantic white space in XML or XQuery.

People do have strong presentation preferences, but those need to be something managed by a presentation layer, not considered an aspect of the code expression. Especially not a code expression internal to the processor which is being exposed as debugging information. (I say this as someone who configures editors to make punctuation a different colour than letters, and digits a different colour than either.)

The BaseX GUI is extremely lightweight as a matter of conscious design intent; it's not going to take on features that allow a highly configurable presentation layer. This is not to say I don't wish oXygen had out-of-the-box integration with BaseX; I do. But I also have to recognize that the tools I'm using (in the BaseX GUI case) are specifically designed to be minimalist and specifically designed to not care about white space in the XML case because that was a design decision about XML back in the bright beginning.

I would occasionally like to work with multi-line information which will

be provided by data structures that are not XML formats.

The best practice is the same as the best practice for encodings other than UTF-8 (or notionally UTF-16); you convert the source data on the way in, handle it in the expected way, and convert to the target encoding, format, or data structure on the way back out.

Whether in the case of multi-line information that's handled by conversion to an XML representation on intake, or by an encapsulating function at processing time, or by something already in the static context (such as csv:parse() in BaseX) is a lot less important than avoiding trying to make XML care about whitespace. It won't, you can't make it, and the effort leads to frustration. (The world is full of people marking up addresses with new lines, even in XML data; sometimes it's an empty newline element, rather than a newline character. Sticking the line worth of text into an element makes everything simpler.)

-- Graydon

On Tue, Apr 12, 2022 at 12:24 PM Markus Elfring Markus.Elfring@web.de wrote:

...

...

How much do you care that the display for the item “Query” would be

equivalent to

...

...

the original XQuery script (including special characters like line

breaks)?

...

Not at all.

Interesting.

...

U+000A LINE FEED is one of three control characters allowed in XML.

I would occasionally like to work with multi-line information which will be provided by data structures that are not XML formats.

...

It's inherently special, but it's also white space, and white space is

not important.

Can any more special characters become relevant for further data processing?

...

The query itself is not in and must not be in a presentation format where white space has semantic meaning.

The presentation variant “Optimized Query” can preserve mentioned details.

...

I've been doing mostly document-representation XML processing for twenty-odd years now.

Thanks for such background information.

...

There is no business case for pretty, stable indents, or semantic white space in XML or XQuery.

I got other impressions and expectations for some use cases.

Regards, Markus