... was thinking if these metadata nodes would also exist for binary database resources or only for xml documents and collections.
Cheers, --Marc On Tue, Sep 2, 2014 at 2:24 PM, Marc van Grootel <[email protected]> wrote: > 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 -- --Marc
