Re: [xml-dev] How to represent step-by-step procedures in XML?

[Damian Morris <damian@moso.com.au>]

Further to Michael’s point, this is a great example of the 80/20 rule - in this case, that around 80% of your code (in a thorough implementation) will commonly be required to deal with exception cases, and only around 20% will handle the actual process you thought you were implementing (ie, the “success” path).

That means that 80% of your code is super-boring “check for this unexpected outcome and deal with it intelligently” code, rather than interesting “solve this interesting and difficult problem” code.

Of course, the most common case by far is that the boring 80% is only patchily implemented, if at all.

Cheers,

Damian

On 21 Aug 2022, at 9:23 pm, Michael Kay <mike@saxonica.com> wrote:

I am seeking a high-level XML representation, one that is understandable by a manager and at the same time is sufficiently detailed that it can be executed

That's the holy grail of computer science - ever since COBOL, people have been trying to find a language that was simple enough for managers to understand but precise enough to express all the detail. No-one has succeeded. I don't think it's a language problem; I think it's an abstraction problem. "Managers" want to reason about the process at a level of abstraction that doesn't involve the sordid detail (handling of exception cases, in particular) that's needed to make the process executable.

I remember well a conversation with the marketing manager of a cable TV company, talking about the process for on-boarding new customers. We kept asking "what if" questions, and the manager got quite frustrated: he was only interested in the success case where everything went smoothly, and wanted someone else to worry about what to do when things went wrong. His staff in the call centre were also quite frustrated: 90% of the calls they took were dealing with things that went wrong, and that weren't covered by the process manual.

An executable process needs to deal not just with the things that often go wrong, it needs to deal with all the things that can ever go wrong, and that's a level of detail that most managers simply aren't interested in.

Michael Kay

Saxonica