Cart
[Home] [By Thread] [By Date] [Recent Entries]
"Hunter, David" wrote: > In my mind, this is not a bad thing. As some people may or may not be > saying on this thread, the word "purchase" means different things to > different companies, so they are naturally going to write XML to define a > "purchase" differently. So the key word I see in that last sentence is > "basically". "Purchase" may mean <em>basically</em> the same thing to two > different companies, but they won't mean <em>exactly</em> the same thing. This quality is fundamental to the nature--and to the appeal--of XML. The great advantage of XML as a data interchange mechanism is that it abstracts an understanding of data items and of data structures--e.g. '<purchase>'--from their specific realization on either the originating or the target system. The same is true of process, and with process that abstraction is even more valuable. Ultimately, process is the reason for exchanging these XML data structures. You are sending me an element tagged <purchase> because of the processing I will perform--the commercial transaction I will execute--on that element. Not only might I define a different structure than you within an element of that name, but I am most likely to perform a different process on it than you can. That is, in fact, why you send me an instance of that element: you have a commercial need for the processing which I perform upon such elements. That processing is the expression of the role which I perform in the transaction. You send that element to me (or I pull it from some neutral place where you have posted it) because I have the ability to do something useful--some process--with it. > <aside> > As has been mentioned before, I think this is one of the areas where XSLT is > really going to shine over the Internet. Even when we start coming up with > <em>standardized</em> ways of expressing things in XML, people don't have to > use those standards for their own applications. They can write XML in > whatever way they want, in a way that makes sense for them, and transform it > to another form of XML when they need to communicate with someone else. > </aside> Yes, this sort of transformation is necessary, but it should be handled by software, relying on database tools to derive and to manipulate the different implicit schemata which can be mined from the past correspondence with each other node. And, the transformation should be done on the *receiving* node: only the receiving node knows exactly how it would like to instantiate an element tagged <purchase> by a particular correspondent. Only the receiving node defines the particular processing which it would like to initiate upon instantiation of that element. And if in time the nature of that processing changes, that node's correspondents will have no way to know that, nor to know how their <purchase> elements are now being differently instantiated at that node. Respectfully, Walter Perry 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/ and on CD-ROM/ISBN 981-02-3594-1 To unsubscribe, mailto:majordomo@i... the following message; unsubscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
