[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Three Access Language Paradigms
At 03:14 PM 11/18/97 -0500, Joe Lapp wrote: >We would like clients to be able to remotely manage documents >residing on servers. Clients need to be able to both query >and edit those documents. and later, >This approach is based on a different way of thinking about >documents. Instead of asking document repositories to look >like XML documents to the external world, we only ask that >the repositories speak XML with the external world. DTDs >would be defined for the protocols that repositories might >care to speak. The DTDs would define the structure of the >protocol messages rather than the structures of documents. >One repository might speak several protocols (e.g. 'Patient >Records Protocol V.152' or 'Bank Transaction Protocol 2A'). >If the repository were capable of containing arbitrary XML >documents, the repository might speak a specific protocol >called 'XML Document Protocol V.1.0'. I am not sure that the term "document" is clearly defined for your usage. The problem I see is that a user might change a "Document" which then affects a number of other "Documents" because they are all just abstracted views of a database. This breaks my own intuitive definition of "document" which I would normally use to interpret your first statement. There are no "Documents residing on servers", but only documents which are generated as part of a interchange protocol. Or do you mean that there are documents (A) (which may not be XML) and then there are XML "documents" (B) which are generated as part of the protocol to interchange the documents (A)? I am in complete agreement about the use of XML for information interchange. XML helps solve a number of the problems which CORBA users are facing currently, esp. in situations demanding high levels of information content in each query. CORBA is great for a simple (to formulate & express) query which a server has to think hard about and can eventually deliver a simple (to express) answer. XML is excelent for situations where either the query or the responce is not so easily simplified, and structured data interchange is desired. An example I have worked on is that we have a java applet which presents an expandable tree view of some data. The full tree is _very_ large, and the network connection may not be fast, so we deliver segments of the tree, using XML, to the applet, as requested. Thus the user does not need to wait for information they do not need. In a production system the server could analyse the network connection to determine aproximate-optimal packet sizes. CORBA is horrible for this type of thing, relative to our implementation, since we can deliver N nodes of a tree-graph in one network transaction, while CORBA would require 1 transactions for each node. (yes there are work-arounds, but the XML solution is the simples, and most versatile I have seen yet.) Another thing which XML solves when used as a protocol is the problem of adding information to an existing protocol without breaking existing implementations. This is a serious concern. Try and load a Word97 document into Word95 and you will have a number of problems. Same with different versions of PDF. With NAMESPACES, or some carefull DTD and implementation design, it is possible to use XML so that this is no longer a problem. For example, you have a NAME field, which is currently interchanged via a NAME element like this: <!ELEMENT NAME - - #PCDATA> If the implementations are designed to ignore unknown element tags, then you might have (in the next version of the protocol) <!ELEMENT NAME - - ((FNAME, LNAME) | #PCDATA)> <!ELEMENT FNAME - - #PCDATA> <!ELEMENT LNAME - - #PCDATA> which can handle to the old protocol format, and a new format with more "meta-info". This strongly appeals to me, since this not only applies to protocols but configuration info, etc.. the applications are virtually unlimited. Suddenly I can share information amonst tools without having to succumb to the least-common-denominator problem. With regard to the protocol issue, we now have a MIME-ish thing with extensibility! So the point of my responce, is that some of the ideas in your original most strike a significant cord with my own ideas, but that the language for a discussion of these topics is not clear. There is also an problem that the real requirments for what you (Joe) are trying to do are extremely fuzzy at this point. A clearer language for talking about this is needed (clarify some terms) and the requirements of what you are trying to do need to be specified more clearly. -derek Derek E. Denny-Brown II || ddb@c... "Reality is that which, || Seattle, WA USA when you stop believing in it, || WWW/SGML/HyTime/XML doesn't go away." -- P. K. Dick || Java/Perl/Scheme/C/C++ 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
|