Gianugo Rabellino wrote:
Murray Altheim wrote:
I've posted the API documentation for XNode to:
http://kmi.open.ac.uk/projects/ceryle/docs/api/org/apache/xnode/package-summary.html
Thanks Murray, finally I had some time to sat down and give a look to your proposal. Sorry for my delay, but it's being a crazy time here.
Understood. No problem, things are pretty much the same all around.
Some quick questions to start:
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.
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.
- 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.
- 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.
3. I'm a bit puzzled about the idea of wrapping documents into XNodes. Not that I dislike the idea, but this looks to me like an alternative way of accessing an XML database, a sort of competitor to the XML:DB API.
Hmm. I'm using both right now, so I don't quite understand. XNode isn't IMO competing with XML:DB so far as I see. There are many ways of accessing an XML:DB database, this would enable a bit more functionality.
It might be the right thing to do but, if we are going this way, I'd rather explore the alternative of having XNodes as the basic building block for any XML database, wrapping up any possible element of the DB. This means that collections too should be XNodes (and, in fact, they need metadata too, don't they?). This goes in the direction that Stefano and others proposed some time ago, where an XML database could be seen as a huge DOM, where collections are special elements containg sets of XML documents. Might be worth exploring.
I agree that it's probably a good idea to also be able to provide a
metadata solution for Collections, too. One of the design goals for XNode was to avoid the most common mistake I've seen in the past decade of standards work: making things more complicated than is really necessary. XNode looks a bit like SOAP syntax, but look at the Simple Object Access Protocol now: it's anything but "simple." I really want XNode to be at the SAX 1 level of simplicity, not the RDF/RDF Schema/XML Schema level. Something simple and easy to use. I think it might not be too difficult to add an XNode wrapper around a Collection, but it might mess up other things like XPath or XUpdate processes that aren't expecting an XNode root element. Dunno.
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.
Thanks for the comments. Perhaps we can work out what seem like a couple of misunderstandings.
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