Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Query Languages for XML
 At 04:20 PM 11/15/1997 -0500, you wrote: >[...] >> I think the question being asked is whether you could make an input-text >> flow object which had a clearly defined semantics in altering your XML >> grove, not your flow object tree. For this, you would need an abstraction >> for the form submission/editing cycle, and such SDQL primitives as richard >> was mentionning. > >Only if you take the approach that DSSSL code must manage the form >interactivity process. I don't see why it must. It seems simplest to >methat it should do the moral equivalent of "put a button here" and >leave the processing of the button click to JavaScript, Java or C++. A standard, platform-independent query language has its merits: (1) Many people use SQL without knowing a thing about programming. It's easier to learn a tiny language than to have to learn a big language in order to make use of a tiny library. SQL is very useful as a filter- specification language. This allows database administrators to manage a database by specifying complex filters that the database tool uses to select the elements to process. The user does not have to know the language in which processes are defined. Imagine trying to manage a database by having to write a different program (or plug-in) for each query operation you wished to perform. (2) If the query language were defined as APIs (interfaces or IDLs) for use in an existing programming language, a person versed in manipulating a database from one language may find his skills of less value when he's asked to manipulate a database in a language he does not yet know. An administrator's skills (or DB developer's skills) are much more valuable if they are directly usable in many different environments. (3) If a query must be expressed in a particular programming language, that query will not be directly usable in other programming languages or other environments. It is very likely that the query would have to be embedded in a plug-in module (or COM component or JavaBean), and that module will not be directly usable in any other environment -- perhaps not even outside the original application for which it was intended. If a standard language were used, applications could share queries, queries could be stored away for future retrieval, and users could share each other's queries just by handing each other files. >[...] The SQL model (I'm not familiar with OQL) is that a host >language (COBOL, PowerScript, JavaScript, Java, whatever) handles the >interactivity and issues data model update instructions. SQL does not >handle the user interface itself. OQL looks very much like SQL, except that it has extensions for accessing object-oriented databases, and except that it throws out the non-object-oriented update mechanisms of SQL. It still uses the SELECT ... FROM ... WHERE syntax. However, both SELECT statements and object methods can return result sets that can be further operated on. OQL does not have the UPDATE or INSERT statements. To perform equivalent actions you must use methods on objects. Such objects might be individuals or the objects in collections retrieved via the query semantics. >In other words, the vast majority of forms will have nothing to do with >the document grove itself. They may be forms designed to talk to >relational databases or object databases or CGI or whatever. We can >create these forms immediately, without touching SDQL. Yes, it would be >cool if SDQL allowed grove updates, and of course we expect that if it >did, you would be able to call it from the code that handles your >button, just as you could call SQL or OQL etc. I think there is a whole class of applications that could arise from being able to manage XML documents from clients. Consider knowledge repositories that retain data in a semantic form (in XML). Users could perform semantic-based queries and updates and all participate together in generating a semantic model and information warehouse. It may be that existing applications won't have much use for the kind of query language I'm proposing -- I'm looking toward the future. >Anyhow, I think that the DOM allows updates, so if you use DOM functions >as your "query language" and the DOM model as your grove, then you will >have a read/write document query language. This is a very significant point. I expect that DOM will define query operations on its objects, so that via IDLs, programs will be able to remotely manage persistent XML databases. However, for reasons I've given in other posts, I think an XML-based query language is necessary. The form of that query language might mirror the form defined by DOM, but the query language will necessarily provide constructs not named by DOM. DOM assumes the existence of a Turing-complete programming language. Just as SQL has, we would need to have mechanisms for piping filters through each other and for performing operations on the result sets. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...) 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
