Shared Semantics for Dynamic Interface Discovery

[s***@yahoo.com]

There are a few protocols (both Application-level and Transport-level)
out there that claim to be geared towards dynamic interface discovery
(e.g. CORBA-DII). I have never been able to fathom the concept in its
entirety. To me it appears that there is really not much you can do
if you discover an interface about which you have no compile-time
semantical knowledge. Can someone kindly shed some light on this? I
mean, what exactly can we do if we discover an interface definition at
run-time? Wouldn't it require some level of human intervention to do
anything meaningful? I may be able to discover the names of
operations are supported, the names and types of parameters are need
to be passed, the data-type of the result that is returned etc., but
so what? Unless I know the behavior associated with each operation,
what good does it do me? And I can almost challenge that there is
absolutely no way in the world we can capture semantical details
associated with interfaces.

We got into this discussion at work while we were discussing this
problem on a smaller scale. Can we do anything about a blob of data
for which there is absolutely no compile time knowledge of its
underlying data structure but for which an XML description of the data
structure is provided at run-time? Again the same issue. Can we
really do anything meaningful with this data? I have given it some
thought and concluded that the only thing that can be done with this
blob of data is at the PRESENTATION LEVEL ONLY. Yeah, we might be
able to display the data correctly in some user interface, but that's
about it. Again I challenge that we can do nothing with this data
beyond the presentation level. One of my colleagues thinks that with
a run-time XML description of data we can populate the data in a
relational database and let some other application take it from
there. Now this may be possible, but aren't we merely shifting the
problem?

My philosophical argument is that any claim to do anything meaningful
with either interface or data for which there is absolutely no prior
knowledge, without human intervention, is complete humbug. To do
something meaningful we need to have shared semantics between the two
entities. In all the hype of dynamic interface discovery and self-
describing data, no one talks about the need for shared semantics.

I would like to know what the wider community of netizens, who are
infinitely wiser than me, think about this issue.

Regards,
Sandeep

[Le Chaud Lapin]

Post by s***@yahoo.com
There are a few protocols (both Application-level and Transport-level)
out there that claim to be geared towards dynamic interface discovery
(e.g. CORBA-DII).  I have never been able to fathom the concept in its
entirety.  To me it appears that there is really not much you can do
if you discover an interface about which you have no compile-time
semantical knowledge.  Can someone kindly shed some light on this?

Yes: You're right, and the other people are wrong. :)

Post by s***@yahoo.com
mean, what exactly can we do if we discover an interface definition at
run-time?  Wouldn't it require some level of human intervention to do
anything meaningful?  

Yep.

Post by s***@yahoo.com
I may be able to discover the names of
operations are supported, the names and types of parameters are need
to be passed, the data-type of the result that is returned etc., but
so what?  Unless I know the behavior associated with each operation,
what good does it do me?  And I can almost challenge that there is
absolutely no way in the world we can capture semantical details
associated with interfaces.

And isn't it extremely irritating when the people you argue with imply
that it is possible by pursuing this fruitless path, but always seem
to "have to go to lunch" when you call them out on it?

Post by s***@yahoo.com
We got into this discussion at work while we were discussing this
problem on a smaller scale.  Can we do anything about a blob of data
for which there is absolutely no compile time knowledge of its
underlying data structure but for which an XML description of the data
structure is provided at run-time?  Again the same issue.  Can we
really do anything meaningful with this data?  I have given it some
thought and concluded that the only thing that can be done with this
blob of data is at the PRESENTATION LEVEL ONLY.  Yeah, we might be
able to display the data correctly in some user interface, but that's
about it.  

These types of people are *the* most annoying kind of smart people.
They are the Hoare's (pun intended) of the software engineering
world. I would not be suprised if the person you were arguing with
also believes that there is some generalized lock-free mechanism with
no machine-specific synchronization support that we simply have not
discovered yet.

Post by s***@yahoo.com
Again I challenge that we can do nothing with this data
beyond the presentation level.  One of my colleagues thinks that with
a run-time XML description of data we can populate the data in a
relational database and let some other application take it from
there.  Now this may be possible, but aren't we merely shifting the
problem?

Yep.

Post by s***@yahoo.com
My philosophical argument is that any claim to do anything meaningful
with either interface or data for which there is absolutely no prior
knowledge, without human intervention, is complete humbug.  To do
something meaningful we need to have shared semantics between the two
entities.  In all the hype of dynamic interface discovery and self-
describing data, no one talks about the need for shared semantics.

Because they cannot.

Post by s***@yahoo.com
I would like to know what the wider community of netizens, who are
infinitely wiser than me, think about this issue.

I certainly agree. See post #4 of this thread:

http://groups.google.com/group/comp.lang.c++.moderated/browse_frm/thread/cd3ceb807bf9f3ac

About the person you were arguing with:

You probably already know that you and he will never see eye-to-eye on
this matter. His perspective on design is a manifestation of
fundamental differences in the neural-interconnects between your
respective minds.

One way to weed out people like this during an interview is to take a
stack of 100 sheets of blank paper, lock him in a room, and tell him
to architect, in excruitating detail (with code), before leaving the
room, a system of moderate to great complexity, making sure you
impress upon him the need to be specific [red-black tree for set vs
straight binary tree, etc.]

If he starts sweating, he might not be what you are looking for,
because people who think in that manner often find displined
forethought toxic, a quality that just happens to be a prerequisite
for being a good engineer. Another dead give-away is if the person
insist on interacting with you or other members of the interviewing
team while doing the design.

Incidentally, the whole notion of .COM and interfaces (and some
aspects of .NET) foll into this category of meandering modes of
thought.

-Le Chaud Lapin-

[Patricia Shanahan]

***@yahoo.com wrote:
...

Post by s***@yahoo.com
We got into this discussion at work while we were discussing this
problem on a smaller scale. Can we do anything about a blob of data
for which there is absolutely no compile time knowledge of its
underlying data structure but for which an XML description of the data
structure is provided at run-time? Again the same issue. Can we
really do anything meaningful with this data? I have given it some
thought and concluded that the only thing that can be done with this
blob of data is at the PRESENTATION LEVEL ONLY. Yeah, we might be
able to display the data correctly in some user interface, but that's
about it. Again I challenge that we can do nothing with this data
beyond the presentation level. One of my colleagues thinks that with
a run-time XML description of data we can populate the data in a
relational database and let some other application take it from
there. Now this may be possible, but aren't we merely shifting the
problem?

...

I think you can go quite a way beyond display, especially if you can
convert your data to a relational database.

Each relational database manager I've used has come with an interactive
utility that does various forms of inport and export, as well as
executing any valid SQL operation on the database. That allows changes,
as well as display. I've used one of those programs to do non-trivial
work on a database that did not exist when the program was compiled.

Of course, that does combine the program's user's knowledge of data
semantics with the program's knowledge of the nuts and bolts of
operating on a database.

Patricia

[Le Chaud Lapin]

Post by Patricia Shanahan
Each relational database manager I've used has come with an interactive
utility that does various forms of inport and export, as well as
executing any valid SQL operation on the database. That allows changes,
as well as display. I've used one of those programs to do non-trivial
work on a database that did not exist when the program was compiled.

Which program?

There are two programs:

1. The program that is RDBMS.EXE, written in C++, that interprets SQL
statements, among other things.
2. The program written in SQL that is interpreted by the program
written in C++.

Any instructions expressed in either the former or the latter will
have specific, predictable outcomes under all prescribed scenarios.

Post by Patricia Shanahan
Of course, that does combine the program's user's knowledge of data
semantics with the program's knowledge of the nuts and bolts of
operating on a database.

I sandeep is saying "software cannot think." There is no magic.

One has to weary of people using expression like, "It consumes XML",
for example.

I think this topic is extremely important because there are thousands
and thousands of engineers all over the world waiting in vain for
software to grow legs and start walking.

Even worse, they impose their philosophy on others in subtle and not-
so-sublte ways.

The waste in real productivity is enormous.

-Le Chaud Lapin-

[Logan Shaw]

Post by s***@yahoo.com
There are a few protocols (both Application-level and Transport-level)
out there that claim to be geared towards dynamic interface discovery
(e.g. CORBA-DII). I have never been able to fathom the concept in its
entirety. To me it appears that there is really not much you can do
if you discover an interface about which you have no compile-time
semantical knowledge. Can someone kindly shed some light on this? I
mean, what exactly can we do if we discover an interface definition at
run-time? Wouldn't it require some level of human intervention to do
anything meaningful? I may be able to discover the names of
operations are supported, the names and types of parameters are need
to be passed, the data-type of the result that is returned etc., but
so what? Unless I know the behavior associated with each operation,
what good does it do me? And I can almost challenge that there is
absolutely no way in the world we can capture semantical details
associated with interfaces.
We got into this discussion at work while we were discussing this
problem on a smaller scale. Can we do anything about a blob of data
for which there is absolutely no compile time knowledge of its
underlying data structure but for which an XML description of the data
structure is provided at run-time? Again the same issue. Can we
really do anything meaningful with this data? I have given it some
thought and concluded that the only thing that can be done with this
blob of data is at the PRESENTATION LEVEL ONLY. Yeah, we might be
able to display the data correctly in some user interface, but that's
about it.

I think I agree with where you're going with this in general, but I
don't think it's quite as limited as that.

Yes, you can do something meaningful with the interface discovered at
runtime. This is trivial to show: you just define an interpreted
language, write an interpreter for it, and allow it to access the
discovered interface. To do anything useful requires someone to
provide you with a program written in the interpreted language, but
the question (as you phrased it) was whether it was possible to do
anything useful other than present the data, and the answer to that
is clearly that it is possible, although it may not be anyone's
preferred way of doing it.

Also, I suppose you could apply any sort of set of semantics that
takes the interface as a parameter. You mentioned transliterating
the values so that the user can interact with them on a very literal
level[1]. That is one example of a set of semantics that is
parameterized by the interface. Another example might be some
sort of service availability test for people who monitor a
critical application at a data center: code could discover an
interface, then a user could select which method looks harmless
to call as a test of the application's availability. The code
could then make the call repeatedly and sound an alert if the
call takes longer to complete than N standard deviations above
the mean, or just more than some number of milliseconds, specified
by the user. Yet another example would be to compare two interfaces
to see if they are syntactically equivalent; this could be useful
for managing software or porting software between one system and
another.

The point here is that while interface discovery doesn't do anything
magic, maybe there are useful things that can be done by composing
together an existing, static algorithm with an interface. The software
is not going to magically sprout the ability to "understand" the
interface, but maybe it's not necessary to understand the interface
in order to do something useful that you couldn't do before you had
the ability to dynamically discover interfaces.

- Logan

[1] Incidentally, the Eclipse IDE for Java has a plugin for SOAP
calls that does this. That is, it connects to a SOAP server
and reads a WSDL (which is an interface definition), and
allows you to make remote method calls by typing values into
text fields. It's a trivial and very literal transformation,
but it also happens to be a very handy interactive tool for
trying things out quickly.

[Le Chaud Lapin]

On Mar 31, 10:28 pm, Logan Shaw <lshaw-***@austin.rr.com> wrote:
[snippage]

Post by Logan Shaw
The point here is that while interface discovery doesn't do anything
magic, maybe there are useful things that can be done by composing
together an existing, static algorithm with an interface.  The software
is not going to magically sprout the ability to "understand" the
interface, but maybe it's not necessary to understand the interface
in order to do something useful that you couldn't do before you had
the ability to dynamically discover interfaces.
   - Logan
[1]  Incidentally, the Eclipse IDE for Java has a plugin for SOAP
      calls that does this.  That is, it connects to a SOAP server
      and reads a WSDL (which is an interface definition), and
      allows you to make remote method calls by typing values into
      text fields.  It's a trivial and very literal transformation,
      but it also happens to be a very handy interactive tool for
      trying things out quickly.- Hide quoted text -

First of all, in case it isn't obvious, I am firmly on Sandeeps side
in discussion. :)

I use the word "side" to emphasize that there are two distinct,
diametrically opposed views on this matter. IMO, it is extremely
important to recognize this distinction:

In one case, a human is allowed to be present, and in the other, a
human is *not* allowed to be present.

In all of the examples you gave above, a human arrives on the scene,
after the fact. What Sandeep has said, and I agree with, is that it
has always been possible for a human to induce a machine to behave the
way the human wants it too.

That is not what the interface "Hoare's" are talking about.

What they are talking about is creating a framework where code can
interact with other code with the same or similiar magic that is
realized when a human [a person with brain and blood vessels]
interacts with a machine, and this is what we are saying is not
possible. Any process that gives the appearance thereof is, by
manifest definition, meaningless, because code cannot think. It only
does what it has been told to do, and for that, you need a human. In
other words, the code is not going to code itself, no matter how many
layers of interpretation you add.

Along a similar line of thought...

There are researchers all over the world seeking to devise tools for
proving the correctness of code, hoping to earn a Turing Award from
their work, but I suspect they know in the back of their minds that
such effort is almost useless, as whatever they devise will, in each
individual case, have to be programmed by a human who has sufficient
depth of knowledge and adherence to discipline that such qualities
might as well have been appplied to the original problem itself, thus
obviating the tool.

-Le Chaud Lapin-

[m***@gmail.com]

Rabbit,

Post by Le Chaud Lapin
There are researchers all over the world seeking to devise tools for
proving the correctness of code, hoping to earn a Turing Award from
their work, but I suspect they know in the back of their minds that
such effort is almost useless, as whatever they devise will, in each
individual case, have to be programmed by a human who has sufficient
depth of knowledge and adherence to discipline that such qualities
might as well have been appplied to the original problem itself, thus
obviating the tool.

The tool's inability to perform magic doesn't render it useless.
"Correctness" cannot be proven automatically, of course, because it
takes a person to define it in every case, and a person to understand
that definition.

It is possible, however, to automatically check proofs that a program
will never crash, will never allow data aquired over the net to be
executed as code, will never get into an infinite loop that the user
can't terminate, conforms to the protocol defined (in machine-readable
format) in RFC XXX, performs the same operation no matter how its
threads get scheduled, etc. These sorts of capabilities would be a
tremendous boon to the industry, and significant advances along these
lines will be worth Turing Awards.

Post by Le Chaud Lapin
What they are talking about is creating a framework where code can
interact with other code with the same or similiar magic that is
realized when a human [a person with brain and blood vessels]
interacts with a machine, and this is what we are saying is not
possible. Any process that gives the appearance thereof is, by
manifest definition, meaningless, because code cannot think. It only
does what it has been told to do, and for that, you need a human. In
other words, the code is not going to code itself, no matter how many
layers of interpretation you add.

The "automatic discovery" people, on the other hand, certainly do
deserve your thrashing, because they _promise_ magic, but you are
making the same mistake here, too. You can't do magic, but Logan
points out some things you _can_ do, and there are many more as well.

Also, the problem with interface discovery is not what you say it is
-- that software can't think. Software can do pattern matching and
heuristics pretty well. One could actually write a program to, say,
find public suppliers for a particular part and get their prices from
their proprietary web services. It would use pattern matching and
heuristics, and it would be able to make pretty good guesses about how
discovered interfaces should be called. The problem with interface
discovery is really that discovered interfaces don't imply a contract
unless it is known a priori that discovery of those particular
interfaces implies a contract. And if you know _that_, then you
already know the interfaces and don't need to discover them.

For example, if I find that your organization has a public web service
called "purchase", with parameters "part" and "shipping address", and
"card number", then I can pretty well guess what it's for, but if I
actually use the service, I can't legally expect you to fulfill what I
_imagine_ your obligations are. On the other hand, if _I_ know that
it is well known that a service like that, with a particular globally
unique identifier, on a particular port, etc., is a public purchasing
point for companies and comes with terms and conditions attached, then
I can indeed call it to buy stuff. With that knowledge, however, I
could just program my system to call it -- no discovery necessary.

Now, this inability to make contracts about discovered interfaces is a
big limitation, but it's not big enough to make the whole process
useless. Imagine that there was a particular namespace in which
interfaces were known to be contract-free? We all know that anybody
can visit a public web site. You can GET to my URL without harm or
foul. What if we all knew that there was no harm in calling whatever
web services you find in anydomian.com/contract-free? That simple
convention would allow a whole bunch of best-effort-based applications
that make use of discovered interfaces in that namespace, in the same
way that the various internet search engines make use of whatever they
can glean from public Web pages.

--
Matt

[bg_fisted]

Post by s***@yahoo.com
To me it appears that there is really not much you can do
if you discover an interface about which you have no compile-time
semantical knowledge.  Can someone kindly shed some light on this?  I
mean, what exactly can we do if we discover an interface definition at
run-time?  Wouldn't it require some level of human intervention to do
anything meaningful?

If by "some level of human intervention" you mean that a human has to
be present at run-time to understand the meaning of the interface, the
answer is yes. However, the point of dynamic interface discovery is
not to take humans out of the picture. The point is to take the
programmer out of the picture. (Alas, the world does not revolve
around programmers)

Post by s***@yahoo.com
 I may be able to discover the names of
operations are supported, the names and types of parameters are need
to be passed, the data-type of the result that is returned etc., but
so what?  Unless I know the behavior associated with each operation,
what good does it do me?  And I can almost challenge that there is
absolutely no way in the world we can capture semantical details
associated with interfaces.

Absolutely no way in the world...? How do you capture and communicate
semantic details in other domains? Hmm... How am I communicating my
meaning with you right now? Oh, yes, words and sentences. You may have
been using them for the last 20-30 years, but they've been around for
a couple of thousand years. Perhaps CORBA doesn't allow for comments
on dynamic interfaces. That's fine. Just document it elsewhere, like,
say, paper. Or a website. Just because the Pacific Ocean doesn't have
a giant floating label on it that reads "The Pacific Ocean" doesn't
mean it can't be labeled as such on a map. The nice thing about using
XML-based formats like WSDL for dynamic interface definition is that
it can include comments.

Post by s***@yahoo.com
We got into this discussion at work while we were discussing this
problem on a smaller scale.  Can we do anything about a blob of data
for which there is absolutely no compile time knowledge of its
underlying data structure but for which an XML description of the data
structure is provided at run-time?  Again the same issue.  Can we
really do anything meaningful with this data?

If you are asking "Can we do anything meaningful with data if we know
the format but not the meaning of the data?" The answer would be "Of
course not." That's a silly question: both the meaning and format must
be known. Knowing it at compile time simply means that it doesn't have
to be known at run-time, because it can be baked-in to the executable
file. To make use of it at run-time requires that a human knows the
meaning and format at run-time. And that's the beauty of XML: it can
describe (to humans) both the semantics and format at run-time. Here
is an example:

Let's say you write an application to compare prices from different
online bookstores, but all you know about the bookstores' data formats
at compile-time is that it will be in XML. If a store sent this XML
documentation to you, do you think you could figure out the price?

<?xml version="1.0" encoding="UTF-8" ?>
<book>
<title>All Quiet on the Western Front</title>
<author>Erich Maria Remarque</author>
<isbn>0-449-21394-3</isbn>
<price currency="USD">19.95</price>
<stock-qty>441</stock-qty>
</book>

The program would not know what <price> means, but it doesn't have to.
The person configuring the application (at run-time) which receives
this XML data would provide the XPath pointer to the XML element that
contains the price. In this case, it would be "book/title/price".
Artificial intelligence is not required to make this work. Just
someone who can read XML and specify which element contains the price.

Post by s***@yahoo.com
 I have given it some
thought and concluded that the only thing that can be done with this
blob of data is at the PRESENTATION LEVEL ONLY.  Yeah, we might be
able to display the data correctly in some user interface, but that's
about it.  Again I challenge that we can do nothing with this data
beyond the presentation level.

If that is your challenge, then you just got served :)

Remember, the argument that machines must be artificially intelligent
to make XML-formatted data useful is like saying that cars must be
able to drive by themselves in order to be useful. These are examples
of a logical fallacy known as a false dilemma.

Post by s***@yahoo.com
 One of my colleagues thinks that with
a run-time XML description of data we can populate the data in a
relational database and let some other application take it from
there.  Now this may be possible, but aren't we merely shifting the
problem?

I don't know what your colleague is talking about. You cannot blindly
populate a database without knowing what the meaning of the data is.

Post by s***@yahoo.com
My philosophical argument is that any claim to do anything meaningful
with either interface or data for which there is absolutely no prior
knowledge, without human intervention, is complete humbug.

Nobody but you (and Le Chaud Lapin) are claiming "without human
intervention." He people who use XML and DID know that humans are
always involved.

Post by s***@yahoo.com
 To do
something meaningful we need to have shared semantics between the two
entities.

Yes. Who is saying otherwise?

Post by s***@yahoo.com
 In all the hype of dynamic interface discovery and self-
describing data, no one talks about the need for shared semantics.

I think I just did :)

+fisting stopped.

[Le Chaud Lapin]

First, I would like to reiterate that there is an *extremely* large
group of "engineers" who subscribe to the mode of thought that Sandeep
and I are questioning.

Post by bg_fisted
If by "some level of human intervention" you mean that a human has to
be present at run-time to understand the meaning of the interface, the
answer is yes. However, the point of dynamic interface discovery is
not to take humans out of the picture. The point is to take the
programmer out of the picture. (Alas, the world does not revolve
around programmers)

Note that the example you give below, the one for <price>, and XPATH,
does involve a programmer, although one perhaps not as sophisticated.
Note also that setting your oven to start baking at 4:00PM and finish
exactly at 5:15 constitutes programming.

Post by bg_fisted
Absolutely no way in the world...? How do you capture and communicate
semantic details in other domains? Hmm... How am I communicating my
meaning with you right now? Oh, yes, words and sentences. You may have
been using them for the last 20-30 years, but they've been around for
a couple of thousand years. Perhaps CORBA doesn't allow for comments
on dynamic interfaces. That's fine. Just document it elsewhere, like,
say, paper. Or a website. Just because the Pacific Ocean doesn't have
a giant floating label on it that reads "The Pacific Ocean" doesn't
mean it can't be labeled as such on a map. The nice thing about using
XML-based formats like WSDL for dynamic interface definition is that
it can include comments.

Comments that are interepreted by humans, or by programs that are
written by humans who had a priori specification of syntax, semantics,
and action to be carried out while interpreting the comments.

Post by bg_fisted
If you are asking "Can we do anything meaningful with data if we know
the format but not the meaning of the data?" The answer would be "Of

Hmm..well, I do not think it is so silly, given that there are a huge
number of engineers who not only have asked this question, but
concluded among themselves that the answer is yes.

Post by bg_fisted
both the meaning and format must
be known. Knowing it at compile time simply means that it doesn't have
to be known at run-time, because it can be baked-in to the executable
file. To make use of it at run-time requires that a human knows the
meaning and format at run-time. And that's the beauty of XML: it can
describe (to humans) both the semantics and format at run-time. Here

You put (to humans) in quotes. Very important qualification.
Obviously, if Sandeep were presented with an arbitray XML file and was
told it contained 8192 "objects", with attributes for those objects,
and he is to make sense of it by writing a program that could organize
it, he would have no problem because he is human and he can read and
he can program.

That is *not* what these pseudo-engineers are talking about. If you
listen closely to their words, you will see that there expectations go
far beyond this.

Post by bg_fisted
Let's say you write an application to compare prices from different
online bookstores, but all you know about the bookstores' data formats
at compile-time is that it will be in XML. If a store sent this XML
documentation to you, do you think you could figure out the price?

Yes, because he is human. The question is...could you write a program
that could figure out any not-yet-specified parameter given abitrary
XML?

Post by bg_fisted
<?xml version="1.0" encoding="UTF-8" ?>
<book>
  <title>All Quiet on the Western Front</title>
  <author>Erich Maria Remarque</author>
  <isbn>0-449-21394-3</isbn>
  <price currency="USD">19.95</price>
  <stock-qty>441</stock-qty>
</book>
The program would not know what <price> means, but it doesn't have to.
The person configuring the application (at run-time) which receives
this XML data would provide the XPath pointer to the XML element that
contains the price. In this case, it would be "book/title/price".
Artificial intelligence is not required to make this work. Just
someone who can read XML and specify which element contains the price.

This is a veiled form of programming. It's like setting up a formual
in eXcel. Yes, the admin assistant might be the one doing it, but it's
still programming, done by a human.

Post by bg_fisted

Post by s***@yahoo.com
 I have given it some
thought and concluded that the only thing that can be done with this
blob of data is at the PRESENTATION LEVEL ONLY.  Yeah, we might be
able to display the data correctly in some user interface, but that's
about it.  Again I challenge that we can do nothing with this data
beyond the presentation level.

If that is your challenge, then you just got served :)
Remember, the argument that machines must be artificially intelligent
to make XML-formatted data useful is like saying that cars must be
able to drive by themselves in order to be useful. These are examples
of a logical fallacy known as a false dilemma.

That's not what we are saying. No one ever said that XML was useless.
What we are saying is that some people who get really excited XML do
not clearly understand that which is making them so excited, and in
the excitement, have unrealistic expectations of what it can do.

I had a friend who got bit by the XML bug a while back. We had
combative arguments about this topic. He was so sure I was wrong. I
was so sure he was wrong. This went on for months. His wife would ask
us not to even talk about it if we were going to fight about it.
Finally, after 8 1/2 months of being patient, we were sitting on his
deck drinking beers watching sunset, and he got this long, pensive
look on his face...and I say, "Whatcha thinkin' about?" and he said,
"I was just thinking about XML" and I say "Yeahhh??" and he says,

"It doesn't _dooooo_ anything."

I nearly fell off the couch. "You *#(!!&%!!! I've been trying to tell
you that for 8 months!!!!"

Anyhow, the point is that, people who fall into the XML-can-make-my-
code-think trap sometimes are so blind, there is nothing you can say
to them to turn them around. I asked my friend at that moment,
"Whatever it was that convinced you to see what you see now, I'd like
to know so I can write it down and post it on the web..." and would
you know? He did not even know that.

Post by bg_fisted

Post by s***@yahoo.com
 One of my colleagues thinks that with
a run-time XML description of data we can populate the data in a
relational database and let some other application take it from
there.  Now this may be possible, but aren't we merely shifting the
problem?

I don't know what your colleague is talking about. You cannot blindly
populate a database without knowing what the meaning of the data is.

Some people think they can write code that can do that. When you
challenge them to do it, they will, in fact, write some code that
does, indeed, make the hard disk plattes spin. And when the code
breaks because it has no artificial intelligence....that is OK because
they can always write more code, in real time, as you complain, to
mitigate any deficiences that you might point out. When you attempt
to impress upon them that they are "cheating", that they are invoking
the Other Computer, they ignore you.

Post by bg_fisted

Post by s***@yahoo.com
My philosophical argument is that any claim to do anything meaningful
with either interface or data for which there is absolutely no prior
knowledge, without human intervention, is complete humbug.

Nobody but you (and Le Chaud Lapin) are claiming "without human
intervention." He people who use XML and DID know that humans are
always involved.

Hmmm...I know quite a few people who thinks they will eventually find
a way to take the human out of the equation. You should go over to
the C++ group. Every few months, someone will announce that they have
"Finally Done It" - found a way to automagically convert from C++ to
XML in both direction using C++ proper. Of course, it never
works...but that doesn't stop them from trying.

Post by bg_fisted

Post by s***@yahoo.com
 To do
something meaningful we need to have shared semantics between the two
entities.

Yes. Who is saying otherwise?

Not sure where you work, but I know of at least one Top-5 software
company that is filled with XML Hoare's. It's actually quite
nauseating. Everything they create is so flexible, it fails to stand
up to anything. Their answer to every thing is "it's flexible."

Post by bg_fisted

Post by s***@yahoo.com
 In all the hype of dynamic interface discovery and self-
describing data, no one talks about the need for shared semantics.

I think I just did :)

He means the "it's flexible" crowd.

I agree with him that this is an area where a lot of engineers have
unrealistic expectations of plastics, ceramics, and metal.

-Le Chaud Lapin-

[Patricia Shanahan]

Post by Le Chaud Lapin
First, I would like to reiterate that there is an *extremely* large
group of "engineers" who subscribe to the mode of thought that Sandeep
and I are questioning.

Post by bg_fisted
If by "some level of human intervention" you mean that a human has to
be present at run-time to understand the meaning of the interface, the
answer is yes. However, the point of dynamic interface discovery is
not to take humans out of the picture. The point is to take the
programmer out of the picture. (Alas, the world does not revolve
around programmers)

Note that the example you give below, the one for <price>, and XPATH,
does involve a programmer, although one perhaps not as sophisticated.
Note also that setting your oven to start baking at 4:00PM and finish
exactly at 5:15 constitutes programming.

...

In that case, we need at least two terms to cover "programming":

ProgrammingA: Any form of control of the future behavior of a device,
such as setting an oven timer or selecting a TV program to record for
later viewing.

ProgrammingB: Writing a solution to a problem in a Turing-complete
computer programming language.

In these newsgroups "programming" without any qualification generally
means what I've called "ProgrammingB". For example, I don't think "How
should I set my oven timer?" would be considered on-topic in
comp.programming.

In my opinion, reducing manipulating some data from ProgrammingB to
ProgrammingA can be a meaningful and useful operation, because it lets
problem domain experts who are not trained in ProgrammingB operate on
the data.

Patricia

[bg_fisted]

Post by Le Chaud Lapin
First, I would like to reiterate that there is an *extremely* large
group of "engineers" who subscribe to the mode of thought that Sandeep
and I are questioning.

The voices in your head don't count :)

Post by Le Chaud Lapin
Note that the example you give below, the one for <price>, and XPATH,
does involve a programmer, although one perhaps not as sophisticated.
Note also that setting your oven to start baking at 4:00PM and finish
exactly at 5:15 constitutes programming.

So any user input into any user interface constitutes "programming?"
Now I know why you call yourself a programmer :)

Post by Le Chaud Lapin
Comments that are interepreted by humans, or by programs that are
written by humans who had a priori specification of syntax, semantics,
and action to be carried out while interpreting the comments.

Wow, comments are for humans: what deep insight you have into the
definition of "comment." And all this time, I thought comments were
for potted plants and elephants.

Post by Le Chaud Lapin

Post by bg_fisted
If you are asking "Can we do anything meaningful with data if we know
the format but not the meaning of the data?" The answer would be "Of

Hmm..well, I do not think it is so silly, given that there are a huge
number of engineers who not only have asked this question, but
concluded among themselves that the answer is yes.

I don't care how many voices in your head say otherwise; it is still a
silly question.

Post by Le Chaud Lapin
You put (to humans) in quotes.  Very important qualification.
Obviously, if Sandeep were presented with an arbitray XML file and was
told it contained 8192 "objects", with attributes for those objects,
and he is to make sense of it by writing a program that could organize
it, he would have no problem because he is human and he can read and
he can program.
That is *not* what these pseudo-engineers are talking about. If you
listen closely to their words, you will see that there expectations go
far beyond this.

And if you listen closely to my words, you will see that I am not
saying that. Neither is anyone else in this thread. Why do you keep
arguing against an opposing position that you keep bringing up? You
are just arguing with yourself.

Post by Le Chaud Lapin
Yes, because he is human. The question is...could you write a program
that could figure out any not-yet-specified parameter given abitrary
XML?

No, that is not the question. I said up front that XML, DID do not
eliminate humans. All these technologies do is make it possible for a
compiled program to handle interfaces and data types not known until
run-time, but it is not the machine that "knows" -- it is a human
being. I don't know why you keep arguing about "there's no machine
intelligence." Someday, maybe, when cyborgs and AIs have become self-
aware and have turned against their creators, but until then, no.

Post by Le Chaud Lapin
This is a veiled form of programming. It's like setting up a formual
in eXcel. Yes, the admin assistant might be the one doing it, but it's
still programming, done by a human.

I said it eliminates the programmer, not "programming."

Post by Le Chaud Lapin
What we are saying is that some people who get really excited XML do
not clearly understand that which is making them so excited, and in
the excitement, have unrealistic expectations of what it can do.

So? Lots of people have unrealistic expectations about lots of things.
Why does it matter?

Post by Le Chaud Lapin
Some people think they can write code that can do that.  

So? They can't.

Post by Le Chaud Lapin
Hmmm...I know quite a few people who thinks they will eventually find
a way to take the human out of the equation.

So? Let them try.

Post by Le Chaud Lapin
Not sure where you work, but I know of at least one Top-5 software
company that is filled with XML Hoare's. It's actually quite
nauseating. Everything they create is so flexible, it fails to stand
up to anything. Their answer to every thing is "it's flexible."

Which company? And why do you care what happens there?

+fisting stopped