[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Data manipulation languages for XML (was Query Languages ...)
At 08:14 AM 11/18/97 +0000, Richard Light wrote: >If so, we need mechanisms to specify changes to existing documents. I >don't really buy the model that says that every change to an XML >document produces a completely new document. You will certainly have a >hard time selling that idea to an end-user who changes one word in a >document, or to a database vendor who has to take back the complete >document and work out for themselves what (if anything) has changed, in >order to update the relevant nodes. I think you're misunderstanding my use of the term "document" and my reference to the *abstract* processing model of DSSSL and groves, as opposed to how an implementation might work or how a user might perceive the result. By "document" I mean what SGML and XML mean by document: a character string conforming to the rules of the standard. Identity for documents is defined by no differences in the character string. If I change one character *I have a new document*. However, when using the term "document" to mean "an abstraction of a container for information", which is the usual everyday meaning of "document", then the document is not a new document, unless the user considers it to be one. Note the difference: I'm talking about the mechanics of data manipulation as related to the formal definition of SGML and XML, users are thinking about the abstractions of information creation. These are two different domains. For the purpose of thinking about standards for defining document processing, it is a very useful simplification to think of every change as creating a new *grove* (which, if used to generate an SGML or XML character string, would result in a new SGML or XML document). Obviously, in an implementation, you would probably not literally create an entirely new grove, but would simply modify the one you have and, presumably, remember the actions that transformed grove[0] to grove[1]. But that implementation approach doesn't change the truth of the abstract model, which is that grove[1] *is a different grove* from grove[0]. That's all I'm getting at. >Also, in the real world you need access control (c.f. GRANT in SQL). >The very nature of XML documents means that this control needs to be at >the node rather than the document level, if only to deal with entities. Not a problem. Remember that we're talking about *editing* here, which *can only happen* on groves, which consist of nodes, which can therefore be individually locked if your editor provides that function. There is nothing in the definition of groves or the DSSSL expression language that precludes node-level access control within an editor. That's an editing issue, which is outside the scope of SGML, XML Lang, or DSSSL (as they are only data representation languages, not editor specifications). >Also, you need to know which parts of the document you are allowed to >change as you start editing - it is not good enough to be told some time >afterwards that certain changes should not have been made! Again, not a problem as long as your editor provides some system for associating access policies with nodes, either directly (by addressing individual nodes) or by algorithm (e.g., elements in context). Again, this is an editor design issue, not a data representation issue. >I agree that you can perfectly well define changes to an XML document >via its representation as a grove, but this grove needs to be linked >back to the physical objects that gave rise to it. For example, if you >edit a phrase that happens to be within an entity that is referenced >more than once within the document you are editing, then perform an >UPDATE, in principle _all_ references to that entity should be updated. What's your point? A grove that includes information about the text entities used to organize it has enough information to correlate references to entities to their content. How could it be otherwise? A grove has to enable *complete* representation of the original document. In a complete grove (one that includes all the properties defined in the property set), the original document can be recreated byte for byte because the original document string is stored as part of the grove (using the so-called "markup" properties). I'm afraid I don't see how using groves as the fundamental abstraction for editing is inconsistent with satisfaction of any of the requirements. All that's needed on top of what DSSSL provides are functions that represent the editing actions needed (as opposed to modeling editing as a transform, which is probably not a useful approach). If SQL provides a useful model for defining such functions, we should use it. Cheers, Eliot -- <Address HyTime=bibloc> W. Eliot Kimber, Senior Consulting SGML Engineer Highland Consulting, a division of ISOGEN International Corp. 2200 N. Lamar St., Suite 230, Dallas, TX 95202. 214.953.0004 www.isogen.com </Address> 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
|