the missing link – BIL

a couple of years ago I was toying with the concept of a behavioural language, and thoughts of this came flooding back to me as I read Rocky’s recent post about SOA.  The problem is not the “service” part of SOA, rather the message is incredibly limited and is basically data centric, not behavioural in nature.
Let’s take a simple example of a real world person to person (autonomous entities) interacting in a “service” based transaction such as banking. In this case consider a loan application.  The first thing is based on a few questions, they will gather the paperwork for the right kind of loan for you.  typically, the form that needs to be filled in will have information about how to fill it in.  There will also be conditional statements, such as “if you under 18… ” etc.
So the interaction is somewhat dynamic.  It’s not like you can have the form already, as the form may change.  So really, the whole UI is in fact the service.  This leads us to thinking a web application or streaming WPF or an updating ClickOnce.
That’s fine if you control both the entire application from server to UI, as Geoff points out.  But what if you don’t ?

For example, if the rules change, such as the fees or minimum payments based on other fields in the data ?  Typically this would require you to re-write this in multiple places 

A service schema can set some basics as per an xsd, such as minimum value or required. but it can do so only statically.  To make this dynamic, to provide a Behavioural Informative Language, the schema needs to be much richer and provide conditional statements, informative descriptive expressions that can be evaluated, and most importantly the ability to refer to other fields in the describing the attributes of a given field.
For example, let’s say you have a first name and a last name property.  The rules should be able to be specified that the field is required if the other one is empty.  That is at least one of those fields must be filled in.
      <FirstName required=”If(IsNull(.LastName), true, false)”>
     <LastName required=”If(IsNull(.FirstName), true, false)”>
Likewise you could use standard operators, IsNull, If(,,) and maybe just a few more descriptive operators to describe the behaviour.
And some behaviours could themselves point to a service.
The idea is the description becomes a lot richer. UI elements could use this to form validation and guide user interaction.

3 Comments so far

  1.   Geoff Appleby on October 9th, 2006          

    I’ve got you all figured out man. You just want a programming language that’s named after you! 😛

    Interesting idea. I’d hate to do the validation myself, but if a framework surrounded it such that from my own code i could query to see what the current values of the requirements are, then that would be quite neat.

    I can understand how a much richer schema definition can enable to code better against it, but how does it become dynamic. Just because it’s more descriptive, that doesn’t do anything to help when a data structure is changed at the service definition to require an extra (new) mandatory field.

  2.   bill on October 9th, 2006          

    nah the love of the language is what I want named after me Behavioural Informative Language Love 😉

    as to the dynamic nature, well the behaviour itself can point to a service

  3.   Kenneth LeFebvre on October 18th, 2006          

    Have you read the book “Web Service Faceplates” by Mohr, Corning, et al? [1] While they describe a rather static UI-oriented faceplate idea, I have often dreamt of a way to incorporate behavior in the faceplate in addition to mere UI, thus achieving a similar result as you describe, I think, without requiring changes to whatever language you might choose to implement with.

    I like the direction you’re headed with this train of thought… I just think there might be a way to get there without requiring that we wait for a new language. 🙂