Last year, several bloggers posted very interesting blogs which touched on the tension that has always existed between business semantics and business syntax. So long as some portion of run-time code is developed rather than generated, "business semanticists" (BPXers) may have to live with the fact that "business syntacticians" (programmers) will always have the last word. Here are two examples of why. Example 1: Radio-Button-Groups Down in the forums, it was recently established that regular ABAP OO does not allow a radiobutton to be made invisible but still be pre-selected. That is, SAP-delivered code will bypass an invisble or inactive button even if it is the "first" button of a group. And therefore, there is no way to "hide" a dummy radio-button to give the effect of a radio-button group with no pre-selected button. But in WDA, you can present a radio button group with no preselected button simply by using "noleadSelection" (thanks to Thomas Szuecs for pointing this out.) So - even though the notion of a "radio-button-group" has been around forever, there can still be differences in the implementation of this purely semantic notion due to differences in business syntax. And therefore, business syntax has the "last word" over business semantics. BTW: 1) in case you're wondering why I call a radio-button-group a semantic notion, it's because this kind of UI element is just a particular way of presenting the semantic notion of "mutual exclusivity" to the customer.; 2) in case you're wondering why you'd want to present an RBG with no preselected default, the answer is that there are some analysts who are scared (rightly or wrongly) that lazy or careless users will always take the preselected default and never change it ... thereby leading to bad-data problems. Example 2: Parent:Child Relations in EQUZ and MAST SAP allows for the notion of parent-child relations in the EQUZ equipment table and also in the material BOM table MAST. SAP also allows a given piece of equipment in the EQUI table to have both kinds of children - children determined from the EQUZ table and children determined from MAST. So suppose the developer is presenting an equipment structure tree. If the developer is not careful, the tree can be coded so that any EQUZ item can have children in EQUZ or children in MAST but not both. And if the analyst is careful not to spec what is wanted for the developer, the business syntax will again have the "last word" over the business semantics. For example, suppose the developer codes the "both" version rather than the "either/or" version. Then this may be correct for some sites but allow bad data configurations for other sites (i.e. sites that don't want both kinds of sub-children.) And vice-versa, if the developer codes the "either/or" version rather than the "both" version, then this may be wrong for the site that does want a piece of equipment to have both kinds of children. Summary These examples are but two of many which tend to indicate that SDNers should pay a lot more attention to Johannes Reich's mini-series on descriptions and models. Although he presents the topic in a very abstract and abstruse fashion, you can see from the two examples above how frequently real-life instantiates the very issues he is talking about.
