Printing Webster on Silly Putty - Making Model Driven Architectures Viable

by Kurt Cagle

I've always been fascinated by dictionaries. We create dictionaries one word at a time, attempting to nail down within a printable tome all of the words the form a language, and for many people such dictionaries represent something immutable, a stamp of authenticity that states that this is the proper way to represent legitimate forms of spelling, legitimate statements of meaning, and in many cases some form of an audit trail that attempts to provide the history of the words.

For all that, dictionaries are fundamentally arbitrary. Someone has to make an editorial decision as to whether a given word is in fact a legitimate word with the language. Is sombrero an English word, or a Spanish one. Is degauss, to remove a magnetic field, a term of technical jargon or a formal member of the language. Is it theater or theatre? My teenage daughter talks about her and her friends being "random", by which she means that she's not easily categorizable to modern marketing efforts. Random, to me, is a stochastic definition that means that there is no readily discernable pattern dictating the results of a given function. While there is some commonality to both terms, they are not the same. Is my daughter's definition of random valid? Is mine?

8 Comments

orcmid
2007-05-19 09:45:25
I think the downside of ontological brittleness and linguistic absolutism may be greater than you suggest here.


I notice, in watching technical fields become popularized, that a certain ontological perversity can actually close off the expression of an important concept. A technical example came to my attention just recently. For some reason, it has become popular to treat the term "algorithm" as applying to any computational procedure and to have computer codes (heretofore, realizations of algorithms) count as algorithms directly. The problem is that there are some profound results in the foundation of computing that apply to an earlier notion. Now there is complete misunderstanding of those results because they do not apply to the conflated popular sense, and this leads people to argue with the results (e.g., the Church-Turing thesis) when what has occured is definitional sleight-of-hand.


There are socially more-significant cases under the guise of "framing the discourse" where, for example, "supporting our troops" means keeping them in harms way.


Coming back to MDA and your practical exercise, one I am keen to see more of, it will be interesting to see how one deals with incommensurate models that are not reconcilable by some mechanical procedure, much as there are expressions and related concepts in different natural languages that do not lend themselves to satisfactory inter-language translations.

John Jacks
2007-05-20 01:06:42
Yawn.


This sounds much like the mental meanderings we go through whilst
sat on the toilet.


Kurt Cagle
2007-05-20 07:54:13
Orcmid,


I don't, in general, see MDAs as being whole solutions. just as I find that XForms is a surprisingly good answer to about 95% of a given problem and very limited in that remaining 5% ... unless you have an extension mechanism that makes it possible to set up additional functionality. There needs to be room for imperative code, the question overall is at what point in the stack the imperative code is introduced. If you can model bindings in a declarative manner, then there are advantages to keeping such bindings as behavior and manipulating the XML as an abstraction before the bindings need to be imposed. The bindings don't disappear - they are a very necessary part of the process, as they impose the notion of componentization - but the idea within MDA is to push such bindings to the periphery of the problem domain - the point where a model gets instantiated as an application.


Your point about algorithms is well taken, however, and one that I have seen as well. Computer code is an implementation of an algorithm, and while it is possible to show from the implementation what the concept behind the algorithm is, a computer program is not (in general) a mathematical proof. However, it can also be argued that there are algorithms which are so complex that they are beyond unaugmented human ability to prove them, with the result that a computer program, particularly one that is generated through computational processes itself (think MathML or Mathematica) may in fact be the only way that the algorithm itself can be, if not defined, then at least described.


As to ontological brittleness - yes, absolutely, I agree with you, and I thought that was what I was trying to say in my original post. Modeling is hard. In many programming applications, the model itself is actually very seldom explicitly stated as such, but rather is much like your algorithm example - it emerges as a fairly amorphous concept that's defined implicitly by the interrelationship of pieces, rather than being explicitly declared. An MDA approach puts the hardest part - development of the model - first, and as such goes against the grain for many programmers. The advantage of MDAs is that once you do have the model (which is generally considerably more than just a formal XML schema, another point I was trying to make) then building the application is trivial and can be nearly completely automated.


MDAs are not a magical panacea, and they generally work best only in those situations that tend to deal with strongly relational data - insurance processing systems, medical systems, process management, workflow situations and the like - systems where the underlying data model can be articulated but may be fluid - such as schemas that may in fact change definitions over time. It's an approach or methodology, and like all such, it is very effective in some domains and less so in others.

Kurt Cagle
2007-05-20 07:54:13
Orcmid,


I don't, in general, see MDAs as being whole solutions. just as I find that XForms is a surprisingly good answer to about 95% of a given problem and very limited in that remaining 5% ... unless you have an extension mechanism that makes it possible to set up additional functionality. There needs to be room for imperative code, the question overall is at what point in the stack the imperative code is introduced. If you can model bindings in a declarative manner, then there are advantages to keeping such bindings as behavior and manipulating the XML as an abstraction before the bindings need to be imposed. The bindings don't disappear - they are a very necessary part of the process, as they impose the notion of componentization - but the idea within MDA is to push such bindings to the periphery of the problem domain - the point where a model gets instantiated as an application.


Your point about algorithms is well taken, however, and one that I have seen as well. Computer code is an implementation of an algorithm, and while it is possible to show from the implementation what the concept behind the algorithm is, a computer program is not (in general) a mathematical proof. However, it can also be argued that there are algorithms which are so complex that they are beyond unaugmented human ability to prove them, with the result that a computer program, particularly one that is generated through computational processes itself (think MathML or Mathematica) may in fact be the only way that the algorithm itself can be, if not defined, then at least described.


As to ontological brittleness - yes, absolutely, I agree with you, and I thought that was what I was trying to say in my original post. Modeling is hard. In many programming applications, the model itself is actually very seldom explicitly stated as such, but rather is much like your algorithm example - it emerges as a fairly amorphous concept that's defined implicitly by the interrelationship of pieces, rather than being explicitly declared. An MDA approach puts the hardest part - development of the model - first, and as such goes against the grain for many programmers. The advantage of MDAs is that once you do have the model (which is generally considerably more than just a formal XML schema, another point I was trying to make) then building the application is trivial and can be nearly completely automated.


MDAs are not a magical panacea, and they generally work best only in those situations that tend to deal with strongly relational data - insurance processing systems, medical systems, process management, workflow situations and the like - systems where the underlying data model can be articulated but may be fluid - such as schemas that may in fact change definitions over time. It's an approach or methodology, and like all such, it is very effective in some domains and less so in others.

Chris Jay
2007-05-21 03:38:49
The question here is: "are dictionaries prescriptive or descriptive"?


Users of dictionaries think of them as prescriptive (because they want to be understood); authors of dictionaries think of them as descriptive (because they want to reflect usage). I don't think that leads to logical issues.


The web has changed the model completely. Wikipedia is written by the people, not by an old British expert, however wise. That makes it much more descriptive (i.e. representative of common usage); and hence it's also much more prescriptive (i.e. an authoritative reference).

Brent
2007-05-21 21:17:43
Kurt,


Love your column and tune in regularly. I recently developed a user-interface framework that is (sort of) MDA. The view is derived from what is essentially an annotated custom schema language. The mantra is "declarative" view. Your point that the schema itself is fluid based on a particular instance is well-taken. The common approach when you have a metadata language that doesn't exactly fit a spec such as CSS or XMLSchema is to map your custom elements or attributes to "named" tokens that in turn map to tokens in a CSS file (e.g. a required field maps to CSS class .required). As options multiply, so do tokens in various languages... I like the approach of having a recognized schema language drive the output of other presentation tags. I wonder how you would approach the problem of embedding custom hooks within standard languages. You mentioned the example of enumerations. In my case, enumerations are more like expanded searched. Results can be presented by category, facet, limited by security role, etc. How would you represent that? In a schema, how do you say something like "given this user and this form data that he's already entered, limit the possible selection for this field to the results of this dynamic query"? For this case, do you go through the pain of extending a known standard or do you go the route of a private DSL that you then map to standards when it is a good match?


Again, thanks for the post. Always interested in what you're up to.


Regards,
Brent

len
2007-05-22 11:09:39
Everywhere you find a link, put a function call.
Kurt Cagle
2007-05-22 13:25:22
Brent,


Kind of working backwards here:


I differentiate in my own efforts between enumerants, which are exclusive tokens or terms that are schematically defined and fixed, and feeds, which are external lists that usually include both an internal token and a label (and which may have additional metadata associated with it). The use of feeds here is meant to (strongly) suggest the association between a feed or resources and an RSS/Atom feed, particularly since I use Atom as my transport protocol for the feeds.


Since I'm using an XForms idiom, the referents themselves are usually defined as an XML data instance -



<xf:model>
<!-- other instances -->
<xf:instance id="myFeedData1"/>
<xf:instance id="myFeedParams1">
<params>
<a>1</a>
<b>2</b>
</params>
</xf:instance>
<bind id="myFeedBind1" nodeset="instance('myFeedParams1')"/>
<xf:submission
id="myFeedGet1"
method="get"
action="http://www.myresources.com/atom/feed.xq"
bind="myFeedBind1"
replace="instance"
instance="myFeedData1"
/>
<xf:action ev:event="xforms-ready">
<submit submission="myFeedGet"/>
<xf:/action>
...
<xf:model>


<xf:select1 ref="someDataValue">
<xf:itemset nodeset="instance('myFeedData1')//atom:entry">
<xf:label ref="atom:title"/>
<xf:value ref="atom:id"/>
</xf:itemset>
<xf:select1


Where atom:id is of the form "EnumerantTypeURI:EnumerantValue".


Thus while feeds usually bear a superficial resemblance to static enumerants, in point of fact they require considerably more resources to support, and in general it is not in fact advantageous for them to be bound explicitly into the static infrastructure. This is useful both for computed lists (such as filtered content, especially content which may change parameterically) and selections that have potentially dozens of potential enumerants and as such would add considerably to the initial download time of the page.


The mappings to generate this are contained in an intermediate tokenized form that's mapped through a couple of XSLTs, as you surmised. I'll try to make that clearer moving forward.