Hi Christian, About the QNames, I was confused, just ignore my remark on that. I realize it now.
I fully agree with you but I'm not convinced that this metadata thing should be extended to all nodes. I see it as a more coarse-grained facility. But maybe others have use cases for such fine-grained metadata. Maybe better to do it like this first and see how people use it? How do you currently think about this metadata and indexes? In Qizx I think that these properties are index so that querying on metadata is very fast. --Marc On Tue, Sep 2, 2014 at 4:49 PM, Christian Grün <[email protected]> wrote: > It would surely be consistent to allow metadata for both binary and > xml resources. > > > On Tue, Sep 2, 2014 at 4:45 PM, Marc van Grootel > <[email protected]> wrote: >> ... 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 -- --Marc
