... 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 marc.van.grootel@gmail.com 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 christian.gruen@gmail.com 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