Thanks, Christian--somehow I had missed the "Set as context" feature, and
haven't taken advantage of the filter feature before, even though I work a
lot in the BaseX GUI.
One small UI change that would make a big difference (to me) would be to
provide a drop-down option for files in the Editor (à la oXygen XML
Editor), instead of scrolling or stacked tabs. I tend to have many tabs
open at once, and neither of the available options is ideal for switching
back and forth. I should probably just use the project view, but I like to
have more space for the Editor window.
Finally, one small issue using the GUI on a MacBook M1 Pro: when I try to
change the interface language from the Preferences menu, it doesn't take
effect after I restart. I have to manually change the .basex config file to
change the language.
All best,
Tim
--
Tim A. Thompson (he, him)
Librarian for Applied Metadata Research
Yale University Library
On Fri, Apr 8, 2022 at 10:20 AM Christian Grün <christian.gr...@gmail.com>
wrote:
> Hi Steven,
>
> Thanks to Hans-Jürgen, the "Set as context" menu item was introduced just
> recently.
>
> And thanks to Tamara: Creating intermediate databases is exactly what I
> do, too. If the query output is a valid XML document, it can also be stored
> by clicking on the “Save” icon in the result view panel.
>
> > I get a shorter menu of options that what’s shown in that doc:
>
> The OS shouldn’t matter. I have Windows, but I’ve just been forwarded a
> 9.7 Mac screenshot (attached to this mail), and it looks correct. Can
> anyone else confirm that the menu is not completely shown on a Mac? Do you
> possibly get output some unexpected errors when starting the BaseX GUI from
> command line?
>
> There is another built-in option to bind the result of a query to the
> context. It works if you have a database opened and if the query results
> are nodes from that database. We called the feature “Filter” (the possibly
> suboptimal term is because this feature was added 15 years ago; at that
> time, BaseX was limited to a simple XPath implementation). If you open a
> database and run a query that yields database nodes as results, you can
> press the filter icon: Your next queries will be based on these results,
> and all visualizations will adapt to show the result nodes on top level.
> With the arrow buttons in the menu bar, you can navigate between the
> previous and next result sets, or you can jump one level up (the
> parent::node() step will then be applied to all nodes in the result set) or
> back to the root nodes.
>
> Maybe we can generalize the filter feature to work on arbitrary results,
> no matter what data type they have. One challenge here is that intermediate
> results can get fairly large, so we shouldn’t include them in the history.
> Next, if the results belong to arbitrary database nodes, we’d need to
> create main-memory copies from these nodes or ensure that the context is
> invalidated once a referenced database will be updated or deleted. Next,
> we’ll have to take care of … Alright, I’ll stop ;)
>
> Further suggestions are welcome.
>
> Best,
> Christian
>
>
> > On Apr 7, 2022, at 1:25 PM, Tamara Marnell <tmarn...@orbiscascade.org>
> wrote:
> >
> > Hi Steven,
> >
> > To save a few clicks, you can create a new database directly from your
> results in XQuery, without saving them to a file first. Instead of
> returning the results outright, assign them to a variable to pass as the
> input to db:create() in the return, with a made-up file name for the path.
> >
> > let $results := <results>{
> > [Your original return in here]
> > }</results>
> > return db:create('my_results_db', $results, 'my_results.xml')
> >
> > Then you can run further queries using db:open('my_results_db')/results,
> and DROP my_results_db in the command input bar when you don't need it
> anymore.
> >
> > This isn't to say a new feature isn't a good idea, just that there's a
> way you can streamline your workflow before that feature exists!
> >
> > -Tamara
> >
> >
> >
> > On Thu, Apr 7, 2022 at 9:49 AM Majewski, Steven Dennis (sdm7g) <
> sd...@virginia.edu> wrote:
> >>
> >>
> >> It would be handy if there was a way to bind results to current context
> for additional inspection/investigation/query of results. Currently, it
> seems, you would have to save results to a file and then create database
> from that file to make an additional query on results.
> >> That binding would be available from editor or input bar.
> >>
> >> Or perhaps alternatively, it could include an option to base
> visualizations on results instead of open database — although I’m guessing
> the former would be easier to implement than the latter.
> >>
> >> — Steve Majewski
>
>
