>> 1. XNode API
>> 2. (Dave Viner's) Metadata implementation
>> 3. JMI-in-Xindice
>
> I think that these are all way of *accessing* metadata, where I agree
> that we have a pluggability spot. My concern, instead, is about low end
> metadata storage which is totally missing and badly needed.
No, I think all three are potentially a mix of both how metadata is accessed and how it is stored. There seems to be two methods for storage:
1. within the database "record" itself, ie., as part of the stored content of an XML node, 2. as a separate XML document
This looks to me more like an implementation detail. It doesn't really matter where you store your data/metadata (in fact even the document itself might be physically scattered over different places). Even with XNode, you could easily have a separate document for metadata and another one for data: it would be just a matter of aggregating the two upon any request (or disassembling them if an XNode comes in). Actually, I think it would be possible, given Dave's implementation, to write an XNode wrapper around it. This is why I'd be happy to see a mimimal metadata support making its way into the codebase.
While you in another message state that databases are all about both data and metadata, that's not necessarily the case. Xindice could be released out the door without metadata built-in. Given a choice between an inappropriate metadata solution and none, some may choose none. If the solution provided is a series of optional plugins, appropriate to different applications, people may then choose the solution that best fits their needs. For example, if *neither* #1 nor #2 solutions are appropriate, say, somebody *requires* a JMI-compliant solution, then even if we don't provide it they could build it themselves (so much the better of course if we provided it). Someone else may want an RDF-based solution, for use with RDF systems. Et cetera.
I don't think so. Think about SQL/JDBC, where you are given a set of "standard" and basic metadata. If that's not enough for your application, you just glue some logic (more tables, triggers) so that you get what you're missing. Here it's just the same: you get the basic metadata (the ones that make sense in a document, like creation/modification timestamps and so on), you get a "property-like"
way to set custom (simple) key/value metadata, and you have all the power of XML in another custom section. So you have almost what you might need to store any kind of metadata, not to mention that you can always write your peculiar logic. If we are to catch the "one size fits all" we're not getting anywhere...
I agree that extremes are to be avoided. But I don't see that wall being hit very soon. I was (for example) able to create a simple metadata API without messing *at all* with the internals of Xindice, and I don't class myself as any sort of remarkable programmer.
Neither do I. This is why I really don't understand how did you manage to create an API implementation without touching the core. The idea of (many) metadata is that they have to be updated automatically as a reaction to evetns in a database (such as creation, modification, deletion). I see no other way but going into the core for that. How did you solve this issue?
I'd hate to commit this early in the communications/designs about an internal API that we'd then be stuck supporting. Look at some of the really bad decisions made in the DOM design that should be changed now, but can't due to installed base. Yuck -- something to avoid.
Yes, definitely I hear that, it's a legitimate concern. But we have to decide on that, sooner or later.
Ciao,
-- Gianugo
