Jonathan Borden wrote: > Agreed, but that's the reason to why I proposed adding a path-prefix > attribute which explicitly sets the context set of the operation. I think > this is very similar to your source attribute, no? I think we are trying to > say the same thing in different ways.
What I gathered from the path prefix is that it was an XPath substring that is automatically concatenated to other xpaths to produce the actual xpath to use. But if our data source can't be encapsulated into a URI then concatenation fails. If anything, I'd suggest having both a source and a path-prefix, and possibly having an aliases tag so that a path-prefix can be used to refer to a source or some narrowing of the resultant set that that source would produce, something like: <data source="(description=(address_list=(address=(protocol=tcp)(host=blah.com)(port=1521)))(connect_data=(sid=ORCL))" alias="oracle" /> and then using <select source="oracle" path-prefix="/addresses" ... When you see scary stuff like that source is where I think we need to support anything rather than only URIs. I can see us possible standardizing a URI format for those who want to implement it as part of sourcing data, but an implementor shouldn't be required to use it. What's good about this is that you qualify what you're talking about. source identifies the data store, and may even be optional if you're in a constrained device or in a context where the data source is implicitly the overriding context of the query. path-prefix then becomes a shorthanding tool for the query itself. >> The first thing we'd be offering is a language that's not yet another >> language that looks like Perl, which is one of Quilt and XQLs primary >> failings. > :-)) Good... I hope there are no Perl fanatics here. > You've identified the need for an XML query language. We might have a goal > that it have the expressive power of say Quilt or SQL as a basis, but use > XML syntax. I agree. I'd definitely think SQL is a better foundation because of immediate familiarity. > Perhaps we should take the DOM as a start (because many vendors have > already implemented wrappers for both) and think about what is missing. > Would it be too much of an imposition to require that result sets are > returned as DOM NodeLists as a starter? Agreed as well. > True, but we need to think about what the minimal requirement for > calling something an XML database are. I would say that the query result > needs to at least be expressed either as a series of SAX events or as a DOM > NodeList What should the requirements for the CLI look like? Do we? I'd like to think that any application should be able implement this update language, whether it can minimally be considered an XML database or not. SAX yucky! Yucky SAX! I'll think about the CLI and get back to the group... It may not be until after we're done with XMLOne and XMLConnections next week. --Tom -- <name>Tom Bradford</name> <title>Chief Software Architect</title> <company>The dbXML Group</company> <phone>(480) 421-1233</phone> ------------------------------------------------------------------ Post a message: mailto:[EMAIL PROTECTED] Unsubscribe: mailto:[EMAIL PROTECTED] Contact adminstrator: mailto:[EMAIL PROTECTED] Read archived messages: http://www.xmldb.org/ ------------------------------------------------------------------
