Sure thing. I think that the three methods in XNode interface:
getContentAsDOM() modifyContentAsDOM() setContentAsDOM()
should have their SAX counterparts, like
getContentAsSAX(ContentHandler handler)
This doesn't make any sense to me. SAX is an event-based API, so
asking a method to return an object would return what?
Of course I'm not suggesting to return anything. A ContentHandler is to be given as the method arguments, and events would be fired on it. This is how it works on many systems, including Xindice.
The whole inner guts of Xindice is about the passing of objects, with the only role of SAX being the construction of those objects during the parsing of some XML content.
The whole point is that DOM sucks big time for a server enviroment, while SAX is *way* faster and lighter. Being a Cocoon guy, I want to work with SAX events, not with DOM objects flowing around.
or, better yet, how about a
Resource getResource(); setResource(Resource resource);
returning an XML:DB resource?
You already have the XML:DB API to do this sort of thing. XNode was
developed to operate at a bit simpler, perhaps higher level, that of
essentially a DOM object (the DOM Document or Element node, depending
on how one looks at it) with the added ability to add metadata due
to XNode's encapsulation. That's it: it's nothing more than that.
Now, please, enlighten me, since I don't see the point. Let's make a very simple example. Suppose that my application should:
1. pull a document from Xindice only if the creation date is newer then a given one.
2. send the content to a TransformerHandler for SAX based XSLT processing.
How does it work? I must get an XNode from an XNodeStore, get my metadata... and then there are only two alternatives: stream a DOM from XNode.getContentAsDOM() (with noticeable overhead) or redo a query via XML:DB and get a Resource as SAX. This is, to say the least, suboptimal. Is it only me not getting the point?
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.
But not all database applications *need* that. XNode allows it, and it's certainly possible to standardize the metadata named properties (such as using DC elements), but I'd resist assuming that *everyone* wants a specific set. For example, my application doesn't need ownership metadata, individual or group. Somebody else does. Now if we were to put a specific ownership property in XNode (ie., hardwired), there very well might be database applications that literally don't agree with that ownership semantic, may have simpler, more complex, or just different semantics. The definitions of a specific property can be quite important in determining its usage. It's not one-size-fits-all.
And this is exactly why I'm envisioning the need for an extensible set of metadata, richer than a simple property set. What are metadata after all if not informations about the data themselves? Those informations are different depending on the application domain: we were sick of having RDBMS's around because they weren't flexible enough to hold our complex sets of data without resorting to complex tables and joins, and we are IMHO risking to fall in the very same trap. This is my main concern. KISS is OK, but it has drawbacks. And simplicity is a main goal, but not the only one.
Anyway, I'm OK with starting with something like your proposal (after all some metadata are much better than none), but I think that it needs some more thinking about the integration with the XML:DB API. At the very least I'd integrate the two with a Service so that it could be possible to work with XML:DB, get a Resource and ask for its metadata. Or the other way around: forget about XML:DB and work with XNodes. But I still see the two as heavily overlapping. More precisely: the major overlap is not between XNodes and Resources but with Database and XNodeStore. Makes no sense to me to have to use them both.
Yet I'd love to see someone join this discussion and help us to come out with a viable and stable proposal: Kimbro? Stefano? Anyone else?
Ciao,
-- Gianugo Rabellino
