> 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.elfr...@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 > >
