On Thursday, January 3, 2002, at 02:11 PM, Timothy M. Dean wrote:

I can't see any use for per-document schemas in my application(s), but
if others see the use in it who am I to dispute that. I would think that
per-collection validation would be more the norm, so that any attempt to
support per-document validation would be in addition to (and not instead
of) per-collection validation.


Whether it makes sense or not depends on the view you take of the database it self. You can view the database as a DBMS for XML data or as a repository for XML documents. If you view it as XML data then making it like traditional databases with per collection constraint makes sense. However, if you take the XML document view then your validation is attached to the document instance and separating it would probably be unexpected.


This is a kind of schitzo pull that has troubled the whole native XML database industry. There are a lot of document oriented things that just don't make a lot of sense in a database (i.e. DTDs, external parsed entities) and there are a lot of database oriented things that don't exist in XML(i.e. joins, declarative updates). You can even see this if you look at specs like XQuery. Even though XQuery is a data oriented spec and is supposed to be for databases it still takes a very document oriented approach to a lot of things.

This is actually an important question that affects the overall development of Xindice into the future. When Tom and I were developing dbXML we definitely leaned in the direction of XML as data. This is why we don't really care about DTDs and such. Now we need to decide if that is the right thing to continue forward in the future or if a more XML document oriented perspective is in order.

The form of Xindice 1.0 is pretty much set, we've put down the ground work and presented one potential path. Now this project needs to decide what is the right path to move down from here. It certainly isn't a black and white situation, but we do need to try to get a clearer picture so that we have some guidelines to help with decisions like this.

This is really a question about how the server is being used today or more likely how it would be used if it did X, Y and Z. What kind of applications are people building? What kind do you want to be building?


Did the discussions of the past yield any results? Was there a consensus
on a preferred direction, even if nobody has worked on it yet? I would
be willing to take a look at some implementations if someone can point
me to discussions of how the desired functionality should work.

- Tim


Kimbro Staken
XML Database Software, Consulting and Writing
http://www.xmldatabases.org/



Reply via email to