Gianugo Rabellino wrote:
Murray Altheim wrote:
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.
Pardon me if I'm seeming daft, but this still confuses me. I certainly
understand the SAX model but I don't see *what would be firing the events*.
You'd do (for example) a query, and the API would fire events? Behind the
scenes it still seems there'd be a lot of DOM transactions, so having a
layer on top wouldn't speed things up at all.
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.
Yes, I agree that the DOM sucks. I was a reviewer on David Brownell's
O'Reilly book on SAX and prefer it in most instances. Maybe I need to
RTFM on Xindice again, but I don't see where SAX fits in. Maybe it
should, but most everything I've been dealing with (as you know by
now) is DOM. JDOM has never materialized as something solid enough for
my taste.
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?
There's no query model in XNode right now at all. So, I've been using
XPath to return content. I'd search on a 'xnode:created' attribute on
an <xnode:Header> element, which would return the element, then get its
parent, the entire XNode. This could easily be hidden behind an API, if
querying were added to XNode. But as you say, currently you'd get a DOM
node, though if you had a reference to the XNode you'd have the ability
to use XML:DB to get it as SAX. XNode would be used only to store and
get the metadata, not the original, stored content. But I do see your
point. It *could* be in XNode and wouldn't force people to use more
than one API (though that in itself isn't a bad thing, since they're
separated across fairly straightforward functional divisions).
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.
I'm certainly interested in hearing more details about this, perhaps
if there is agreement you could assist in the code creation (I'm pretty
booked up just trying to keep up with my Ph.D. work lately).
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?
Yes, please do.
Murray
......................................................................
Murray Altheim <mailto:m.altheim @ open.ac.uk>
Knowledge Media Institute
The Open University, Milton Keynes, Bucks, MK7 6AA, UK
In the evening
The rice leaves in the garden
Rustle in the autumn wind
That blows through my reed hut. -- Minamoto no Tsunenobu
