Musing over Namespaces

[W. E. Perry]

"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 at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo at ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)