Gianugo Rabellino wrote:1. I couldn't find any SAX support in the API. Is that on purpose?
I'm not sure what you mean by this. Isn't "SAX support" rather orthogonal to the design of the API? Maybe an example would help here.
Sure thing. I think that the three methods in XNode interface:
getContentAsDOM() modifyContentAsDOM() setContentAsDOM()
should have their SAX counterparts, like
getContentAsSAX(ContentHandler handler)
or, better yet, how about a
Resource getResource(); setResource(Resource resource);
returning an XML:DB resource?
2. AFAIU metadata, in your proposal, are a fixed set (xnode:created and xnode:modified) plus an extensible and free set of properties based on key/value pairs. Can this be expressive enough? I mean, originally I had in mind:
- a set of fixed metadata a bit more extended than yours (basically mimicking the Unix "stat.h" structure). These are valid potentially for any XML:DB database, they share a common vucabulary and can be expressed as XML attributes;
Yes, but I wouldnt' assume that they are so common as you might suppose, and the wide variety of Xindice/XNode applications would seem to suggest that there may be a number of metadata approaches, where including a fixed set might conflict with the design of one of them, either by name or semantically. After adding the extension mechanism I thought about even moving 'created' and 'modified' and leaving *only* ID. Not everyone needs the same set.
Definitely. Yet there are some metadata that belong to the concept of "document". A document is created, modified, accessed and owned by someone and possibly some group. This is a basic set that IMHO can act as a foundation.
- a set of application-specific metadata (implemented by any vendor of XML database). This is more a matter regarding the XAPI effort;
This is supportable within XNode as is, unless one really needs to be able to namespace the individual metadata elements because one wants to mix them. Even then, the property name could contain the necessary resolution.
OK.
- an extension mechanism based on RDF triplets or some technology of this kind. I'm afraid that plain key/value pairs aren't expressive enough to gather all the possible needs.
I don't see this. In what way does a node-based metadata scheme need the lexical complexity, confusion, and lack of normal XML validation facility of RDF. If your needs for metadata are as complex as that, such as wanting to put Dublin Core in XNode, you don't need RDF to do that, just use the Dublin Core element names. I believe there are docs on their site regarding non-RDF use of DC.
Fine. Yet, as you correctly point out later on:
> My take on metadata and Xindice is that if one's metadata needs are > really that complex, it's likely to be a better solution to keep it > separated from the nodes themselves and use some linking solution, > rather than bloating XNode with a lot of features that not everyone > might want.
This is the whole point. There are two approaches, each with pros and cons. The point is finding a balance between a simple solution that might end up to be poor and a rich one which might be overkill.
It was pointed out many times that it was perfectly possible to write an Xindice based application using metadata stored in parallel collection or some tricks of the like. Now, I'm a bit against it: I don't think that moving this concern into the application domain is a good thing.
I'd rather have hooks directly in the API to do my metadata stuff. And if we are to follow this path, then the API should be as simple as possible yet rich and powerful enough to allow for complex
needs.
This is why I'm a bit scared about the key/value approach, which might bee too simple for many environments. Think about workflow: I think this can be a good candidate for metadata, yet I fail to see how it can be expressed with a simple (yet poor) attribute approach. The DC suggestion is OK, but only for the publishing industry, yet fail short elsewhere.
OK, RDF is overkill. Definitely. But properties aren't probably enough. There might be a balance. Hmm... just a stone in the lake, but how about nested properties? Something like:
<xnode:Property name="changelog" value="1.0">
<xnode:Property name="version" value="0.9">
<xnode:Property name="author" value="Murray Altheim"/>
<xnode:Property name="comment" value="Bugs and fixes"/>
<xnode:Property name="date" value="2002-04-16"/>
</xnode:Property>
<xnode:Property name="version" value="0.9">
<xnode:Property name="author" value="Gianugo Rabellino"/>
<xnode:Property name="comment" value="Initial proposal"/>
<xnode:Property name="date" value="2002-04-15"/>
</xnode:Property>
</xnode:Property>How about this?
Thanks for the comments. Perhaps we can work out what seem like a couple of misunderstandings.
I sure think so!
Ciao,
-- Gianugo Rabellino
