Schema validation in core
-0: I'm with Tom here: I don't think this should reside in the database
core, but if others find it valuable enough to contribute it and if this
doesn't cause internal performance degradation (both speed and memory),
I'd say we accept it.
Except my understanding is that Tom is saying this does belong in the core.
Tom can clarify of course.
Yes. I think an abstract data/content model should definitely be part of the core itself, and should be the only thing that the core itself works with. This would allow us to build out schema implementations as necessary, and just 'plug em in' depending on the developer's needs. Obviously, the first and most important implementation would be XML schemas.
Sure it should. It's very common to expect encryption between a client and a server, it also makes it more comfortable to talk to a Xindice instance over the network. I have a lot of uses where I'd like to access a remote Xindice server directly from my desktop, having the transaction be clear text is a very bad thing. At this point SSL should be relatively simple and ideally should be picked up from our server framework, hopefully for free.
I've been using an SSL enabler for Mac OS X lately. It's very interesting how it works. It basically acts like a transparent proxy. You set up a client daemon on your machine, and a server daemon on the server, then, any normal TCP traffic that is routed to a port on localhost will automatically be proxied via SSL to a port on the server, and then retransfered as standard TCP to the server's local port. A technology like this may be sufficient for most encryption. We wouldn't have to build it out, and it wouldn't bog down Java with encryption operations.
It's a SQL like native XML database query language. It includes a nice set of DML and DDL constructs. It's going to become an XML:DB Initiative project and is pretty much a logical evolution of the XML:DB API and XUpdate. http://www.sixdml.org/
SixDML rockS!
*) node-granular metadata and access control
Node level's going to be really tough. The runtime costs will be huge. I'll add it to the list though.
Node level is going to be tough. I'd opt to offload it into a separately managed service like XNode. One thing we'll want to explore is defining an ID structure that is compatible with the XPath/XQuery data models, partially to allow ID based ordering, but also to allow the kind of node level granularity that a service like this would require.
-- Tom Bradford - http://www.tbradford.org Architect - XQRL (XQuery Engine) - http://www.xqrl.com Apache Xindice (Native XML Database) - http://xml.apache.org Project Labrador (Web Services Framework) - http://notdotnet.org
