May 2001: “XML: the universal language?” https://www.computerweekly.com/feature/XML-the-universal-lan...

I recall a Wired article from the same era. “XML means your doctor’s system can just talk to the hospital system even though they’re different!”

Hasn’t happened yet... will it? Can it?

> Hasn’t happened yet... will it? Can it?

Nope. XML (or Json, etc.) are just "human-readable" presentation of data. It does not provides any semantic whatsoever.

So you need some semantic on top of these data. And a general-purpose, universal API is yet to be invented (hint: it is probably not feasible)

Microsoft and others enterprise selling vendors loved the end goal back in early 2000s - the universal API solved by middleware. That's why you had Biztalk and Biztalk consultants that made more than SAP consultants (think todays crazy Salesfarce consultants that compete for gamification badges). For example you could be a small insurance company submitting to a larger underwriter, and when you work out the transactions per month you have to take $5 off each app just to pay for biztalk infrastructure and licensing. People rode that gravy train hard. I'd be surprise if any of the biztalk shit still remained though, grand goals means juice enterprise sales. Oracle had a similarly crap product that was equally slow, painful and verbose, can't recall the name. XML and it's lofty goals beyond what it was can be compared to today's ICO toxic industry, no reflection on XML itself though.

In the 80's, it was EDI -- electronic data interchange, a set of schemes for sending binary formatted business data, like invoices and POs.

Don't forget HL7

The "badges" are not won in competions, but instead watered down tutorial gold stars. Instead of targeting real programmers Salesforce built "trailhead" for John in finance who wrote some Excel macro and decided he should become a Salesforce "developer". Thats why the small percentage of us consultants who actually come from a cs background can charge so much.

I think I agree with your sentiment, but I'd think you'd be surprised how much a click next salesfarce developer charges...

Of course it's feasible. It's called English!

Quoi? ("...fetchez la vache!!!")

I read a great article about XML that spelled out that XML isn't a "language" or protocol, it's an "alphabet". It gives you the building blocks but what you build with it but it doesn't translate from one language to another. (I guess that's what XSLT is meant to do but it's still not magic.)

JSON? And no doubt in another ten years, something else!

Luckily, the English language never changes. Wait.

But compared to the rate of change in technology, it's practically written in stone!

Much of the "semantic web" work was directed at similar things. The reason we don't have it already after 20 years of web commerce is that it's an adversarial process. The business wants to mislead, upsell, or discourage a customer from asking for support; and likewise some small fraction of customers are looking to exploit the business.

Bots that automate UI tend to get banned.

English, an API with over 1.5 billion clients in the wild

If you think about it, conversation is just a loosely defined API with an extremely high degree of tolerance for poorly formed input.

I mean we are all just emotional processing silos that trade information and process it right :) ?

That’s a very Wittgensteinian view.

This thread now contains a loop. Granted, it's a really long loop, all the way back to 1956, but it's a loop all right: you've essentially summarized the Dartmouth Conference and its assumption "gee, that ought be just a minor research subject - easy, right?"

https://en.wikipedia.org/wiki/History_of_artificial_intellig...

If it was that straightforward, we’d already have bots that pass the Turing Test.

Whatever natural language is, it’s not an API. Might have some overlap, but it’s different.

Natural language is not an API. But a business can assume (or weed out quickly) that caller is calling to hit a specific API endpoint. And as such their language will eventually lead to one of those endpoints.

And similarly, a caller can assume the business they are calling is trying to lead them to an endpoint.

In both cases, a set of assumptions lets natural language act as an API, even if neither end could pass a Turing test with someone who wasn't interested in any of the endpoints.

edit: I read your point about language changing, and that is true. But if we only have machines using the language with each other (no more training with humans), we can also assume the language won't change.

Nobody said it's easy to implement :)

I'm curious - what differences do you have in mind?

APIs map to a single canonical concept. A "class" in Java actually has a correct definition. There are a nontrivial number of philosophers who believe that this isn't true for language.

To simplify that and put it in more technical terms, an API is perscriptive and a language is descriptive.

If a bunch of coders decide to start capitalizing "Class" their code won't compile. If enough people start using the word "aint" it becomes a word, regardless of what the dictionary says (see "irregardless"). There is no single authority that can decide what is and isn't a canonical definition.

This is why spoken languages evolve so much. Even languages where we've explicitly tried to go the opposite direction (like Esperanto) have evolved into multiple dialects, where subsets of the community simply ignore the standards and still communicate with each other just fine.

Note that this is the opposite of what you want with a federated, universal API. The whole point of an API is to standardize between unfamiliar devices. Language is actually pretty bad at standardizing communication between unfamiliar people. Even in the US, different regions and communities use different euphemisms, terms, and definitions.

You're right that the language is not the API, it is the medium. The "appointment booking API" exists only in our heads, it is a set of mutually understood conventions for interpreting a subset of language in order to create a record of the appointment somewhere.

If you call up a hair salon and start reciting poetry you'll get an error response in the same way as you would if you had sent malformed JSON to an endpoint. If you stick to the expected script you'll achieve success almost all of the time.

I wouldn't be surprised if a majority of human communication works this way, especially when it involves individuals who do not know each other. We have agreed upon limits, key phrases and words, and expected responses that allow most of the unpredictable stuff to be ruled out. All of that favours automation.

> We have agreed upon limits, key phrases and words, and expected responses that allow most of the unpredictable stuff to be ruled out. All of that favours automation.

I'm not sure I'd disagree, but it seems you're just describing a domain specific language in a more roundabout way. We have a ton of protocols that introduce a set of limits, key phrases, words, and responses. Java, Network protocols, XML, JSON, etc...

Assuming that you're correct, does it make sense to then assume that it'll be an improvement to standardize English rather than a set of IP headers? The agreed upon standards in English are (for the most part) informal, evolve constantly, and are hard to teach to computers. Automation favors predictability, and even the most generous interpretation of a natural language leaves me feeling like it's a step backwards.

We're going to standardize on an appointment booking API that exists only in our heads, that can only be taught using ML, and that is guaranteed to change over time in unpredictable ways? That seems wrong to me.

Just to add a fun example to demonstrate your point, the original name for Esperanto wasn’t “Esperanto”, it was (translated) “the international language”. It was given the nickname “Esperanto” after the chosen name of the creator, and the word itself it supposed to mean “one who hopes”.

Pedantry ahead: the various implementations of (J(ava)?|ECMA)Script tend to disagree with the point on pREscription and non-divergence (yay 20 MB of stubs and libraries for sort-of-coherent behavior). Moreover, the example of "Class" is just a pre-compile check convention, the compiler doesn't care.

(Postel w/r/t API - Does that make any sense? Or is that a fancy way to say DWIM?)

:) I don't think that's pedantic, it's a really good point to bring up.

On the web side of things, the W3C often describes their role as being partially descriptive.

From their doc on the Web of Things[0]: "The Web of Things is descriptive, not prescriptive, and so is generally designed to support the security models and mechanisms of the systems it describes, not introduce new ones... while we provide examples and recommendations based on the best available practices in the industry, this document contains informative statements only."

This is exactly for the reason you mention - if browsers collectively decide to go in a different direction, what the W3C says doesn't matter. The web standard is what the browsers do.

However, two things to keep in mind:

Even where browsers are concerned, there is still an API and a canonical version of "correct" for each browser. What we're trying to do is get those APIs to be compatible and consistent with each other.

Many people believe that language even on an individual level doesn't directly map to an actual reality; in web standards that would be like the browsers themselves not having their own consistent API.

But assume those people are wrong for a sec. Let's assume that language is just a standardization problem between different communities and individuals. Well, the W3C should teach us that even in the realm of computing, standardization is really stinking hard.

So even in that scenario, we have to ask whether standardization becomes easier or harder when every single individual in a community has the ability to change norms or introduce more language. We can't even get 3-4 browser manufacturers to agree on a single API, now imagine if every single hair salon owner could increase divergence whenever they wanted just by answering phone calls differently.

[0]: https://www.w3.org/TR/wot-security/

True, many people know english, but that doesn't mean they know statistics or some other complex domain. "Show me a k-means cluster of this dataset", is likely to be parsed but not understood by many english speakers.

Fortunately, Duplex's purpose is booking salon appointments, not to provide a conversation partner about statistical theory.

I was attempting to communicate to the parent and grandparent that transcribing/parsing english and communication are different. We both need to share the model being spoken of to transfer or communicate the knowledge.

yep, english is the protocol (like http) and the domain in question (for example booking an appointment) defines the (very loose) api

My god no one in this thread has a clue about the complexities of natural language. English is not a protocol like HTTP, it's a natural language.

I think you may be confused. I suspect everyone in the thread knows that English is a natural language.

Optional functionality :P

word

In a sense you are correct, but remember that Duplex only works because it is limited to a very strict well specified domain: scheduling for restaraunts and hair salons. That is, Duplex only works because there already is a de facto specification for these transactions. It requires a lot less effort overall to just formally specify this de facto standard and deploy it once and for all, but of course a top down approach rarely works. This actually reminds me of the failure of the industry to adopt semantic web technologies. Many organizations are providing the same services and could easily adopt a common “API.”

> Many organizations are providing the same services and could easily adopt a common “API.”

It's not in the interest of those organizations to adopt a common API. Everyone wants to suck in data and be the platform; nobody wants to give data away.

But that's the reason why Duplex is interesting, and why there's a grain of truth in what ZainRiz is saying:

Humans have settled on a de facto API for scheduling appointments. It uses the telephone as its interface, speech as its medium, and Duplex is exploiting it.

...but Google is one of the giants that could pull that off and become The Platform.

You first need "ye old barber shop" and "big corp barber shop" to all agree on what this common API should be. That's the old standards proliferation problem https://xkcd.com/927/

Which is what makes it very hard to define a new common API

However, they all already agree on the standard for natural language communication (in the context of a strict, well defined domain). That's the pre-existing common API which Duplex is using

It's basically what 'pjc50 said - it's not in the interest of businesses to expose their data via a common API.

WRT. using English as universal API, I think this is just dumb. You solve exactly zero problems by going that route, because the actual problems to solve (beyond no incentive for businesses to care) are exactly the same as you have with XML APIs, or any other APIs. The problems of discoverability and machine understanding is something the Semantic Web space has been dealing with for quite a while, and other people before that. Adding natural language to the mix only makes the job significantly more difficult, because you now have to deal with natural language parsing/understanding.

> It's the lack of a universal API.

This sort of thing is exactly why the healthcare industry still uses faxes, even going electronic charts -> pdf -> fax -> pdf -> electronic charts in some cases.

This is even more fun because in the modern age, what very often ends up happening is:

electronic charts -> pdf -> fax -> fax machine as a service -> unsecured email -> pdf -> electronic charts

Compliance can sometimes help, but ultimately the data needs to flow, and people will do whatever it takes to make that happen. Until security is so easy that it's the default, these little loopholes will continue to be abused.

Phaxio co-founder here. We do a _ton_ of heathcare faxing and we're starting to see a shift away from the "unsecure email" in applications. Granted, we can't see what our users are doing at all times but being HIPAA compliant ourselves, we often work with our users to understand their systems and guide them towards compliance.

>> Until security is so easy that it's the default, these little loopholes will continue to be abused.

The simple way to think about this is that the government is more worried about unsecure email/email spoofing than it is about wiretapping.

To be fair, you’ll notice if 150 million faxes start going off rather than someone breaking abusing your API.

Healthcare uses faxes mostly because HIPAA rules particular to format and security of electronic communications don't apply to faxes; it's a compliance hack.

That sounds a bit too juicy to be true. Any citations?

I've literally been in the room when legal and compliance offices gave the advice on both the construction of the relevant regulations and industry practices on which a payer relied on in deciding to use a process that created paper documents then faxed them for certain purposes, but, no, there's nothing published I can link to as to that being the reason industry players make that decision.

I can, however, point you to the relevant section of HIPAA regulations on which it rests, the definition of “electronic media” at 45 CFR § 160.103, specifically this bit: “Certain transmissions, including of paper, via facsimile, and of voice, via telephone, are not considered to be transmissions via electronic media if the information being exchanged did not exist in electronic form immediately before the transmission.”

And in a way it is justified, you need a warrant to wiretap a phone line but no such constraint on eavesdropping on TCP/IP communication.

> if the information being exchanged did not exist in electronic form immediately before the transmission

So you need to print them out before faxing? PDF->Fax wouldn't work with that definition.

The one or both speakers could use a handshake noise at the start of the call to tell the receiver that it's capable of "speaking" a modem protocol. It might change a little every time, or be of an especially low or high frequency so that a person doesn't realize they're talking with a computer. After handshaking, the receiver could send a URL that would allow the channel to be upgraded to the Internet... or not. English is a good fallback if both people speak it and you can't find a more efficient channel.

Revenge of Cap'n'Crunch :D

Now that you mention it, this super advanced AI project sounds like a failure of software standardization rather than a triumph of technology, lol.

> The 3rd party app has to first discover their API, someone has to understand it and write code to use it, and then deploy that code.

I think this would be a better integration point for AI. It could look at the fields and learn to fill them out automatically (name, age) and prompt the user for anything missing. Then instead of the barber shop needing a universal AI users just need their personal AI (or a script) to interact with the API.

Re businesses doing this today: I believe WeChat handles this very well in China.

It reminds me of the maybe apocryphal story how NASA invested time, money, and effort to develop a pen so astronauts could write in zero gravity, and the Soviets used pencils.

A great story, but you are correct about it being apocryphal: https://www.snopes.com/fact-check/the-write-stuff/

And one internet binge later, I am now the proud owner of a matte black Fisher 400B Space Bullet Space Pen. Cool story. (The real one, I mean.)

Sometimes the simple, old, and reliable tool isn't the best one for your environment.

Both used pencils initially, and both switched to this same pen.

Pencils have the disadvantage of putting out conductive graphite dust, which, in 0g, will float around for a very long time.

"Lol, but if you think about it, what stops businesses from doing this today?"

Systems like that are much more expensive than paying a receptionist?

That doesn't sound right. I think you'd pay something like $99 per month for a SaaS product that manages bookings and provides an API. That's how much the average receptionist earns in one day ($12.25 per hour.)

Things that you appear to be missing from your post (but probably totally already know and are just not bothering to mention):

* Most businesses already have a receptionist.

* Most receptionists do not spend measurable fractions of their day answering phonecalls asking when the business is open.

* Taking bookings is really also not the majority of their day.

* Receptionists are capable of a bunch of things that your SaaS booking program is not. Like ordering catering and picking up office supplies.

* A SaaS booking program that is looked over by a human doesn't have to have AI-systems, because they just have I-systems. A human receptionist.

* The inevitable job-post catchall "Other duties as required."

* I had a receptionist bring me a beer once while I was waiting and I'm pretty sure none of your SaaS solutions will do that.

And $20,000 to get someone who knows how to install such a system to do the job.

What is installed when using a SaaS solution?

Well there is initial setup at the very least. Hooking up whatever landline the client has with the SaaS solution.

Then whenever a significant change is required, you need to call back your "expert". New location? xk$, etc.

But I think the biggest concern is that suddently the owner does not understand how his reversation system works. He used to be able to call Joe and know what's going on...

Also, whatever the SaaS system is, I bet you it's significantly less efficient than a receptionist using paper and desktop software.

Web systems are almost never built for productivity.

It is customised against each business model. Some are same, some are different.

The issue isn't universal API, but universal data models which is probably impossible.

Someone needs to maintain that API; update it with the schedule of the stylists or update it for holiday hours, or remove availability for bookings done the old fashioned way.

"This is a problem today because there is no universal Api that all services can use" "It's the lack of a universal API."

I disagree with that. We already have universal APIS. Adopting a newly established Universal Api is far more painful and has slower adoption rate than using the existing-globally-reached one like a telephone. Google duplex like systems addresses a broader scope of computer verbal communication and it feels like a step in the right direction.

What's a universal API that everyone agrees on?

It's the old Standards Proliferation problem: https://xkcd.com/927/

If both sides were to use Duplex, it would already know to just send 1010 instead of verbal communications.

Also if it was unknown whether the opposing person was a bot, a bot could firstly send a common test according to some protocol to ask if the other one was bot by some kind of sound representing that. In which case both would start sending machine readable information to each-other.

Sounds a lot like a dialup handshake.

Or just hang up automatically.

If I remember correctly, CORBA was all about standardizing APIs. You'd have your distributed "CORBA Objects" whose methods anyone who knew the unique object ID could call. The idea was that there would be a "standard library" for each industry. So all the barbers would implement a standard library "Appointment Schedule" object, all the exchanges would implement a stdlib "Orderbook" object, etc.

CORBA would generate RPC stub objects for you in various OOP languages, and potentially automate discovery, so you could say, give me all an array of all the orderbooks of all the bitcoin exchanges, and ask each for the last price.