Hi Christian, With nodes I meant database "nodes". E.g. a database == collection == collection node and a document == document node. I wasn't talking about nodes within a document. I don't think the latter is as valuable as the former. For myself I compare this a bit to the metadata saved in a CMS where folders and documents can get metadata for organizing the documents and being able to locate/find things based on more than just the path or collection name.
Yes, I think strings for keys and values is sufficient. Regarding keys in maps, I would've like to be able to have QNames as map keys but sadly this is not allowed. --Marc On Tue, Sep 2, 2014 at 1:03 PM, Christian Grün <[email protected]> wrote: > Hi Marc, > >> Why do you hesitate about adding API access to such data? Is that a >> technical/complexity or more a design concern? > > One of the reasons is that we have quite a lot of different APIs, and > it takes quite some time to provide new features in more than one API > (which is often a user request if a feature turns out to be > successful). This is why we tend to include new features either via > BaseX commands or directly in XQuery, or in both. > > Maybe we could provide additional commands and add XQuery > functionality in a second step. > > Some more questions: > >> [...] where one, system >> (not an XQuery app) needs to manipulate information on nodes as well >> as nodes themselves that can then be used in an XQuery app. > > * Do you refer to document nodes, or nodes in general? In the latter > case, we could also think about binding properties to node ids. > > * Would it be sufficient to use strings for keys and values? > > Christian -- --Marc
