XML as a programming tool

[Sean Mc Grath]

[Paul Prescod]
>
>ON THE OTHER HAND, protocols should be rare in good software design. You
>can usually define an interface so that it doesn't require much explicit
>time ordering. For instance you can open file objects automatically when
>they are created and close them automatically when they are destroyed.
>-- 

Oh, I'd have to disagree with you there!

In many problem domains object abstractions
are used to represent things that have a life history: bank accounts,
customers, space flights
etc. Recognising and leveraging the natural time ordering of the events that
occur to
these objects can be both powerful and natural. Grady Booch et al have
written about a variety of
ways to do it: time lines, flow diagrams etc. IMHO SGML/XML can gainfully be
applied in this
field.

I made a stab at it at SGML '96 in Boston when I gave a paper that compared
SGML DTDs
with the ideas in the JSP and JSD software development methodologies.

I would argue that *not* utilising the natural time ordering of events
inherent in many systems
is one of the things that can make event driven programming a real dog.
How many times have you seen this:-

if (event == OPEN) {
        if (ALREADY_OPENED==TRUE)
                barf();
        else {
                ALREADY_OPENED=TRUE
                do somthing useful.
       }
 }

In SGML/XML, very analagous  sort of stuff results from loose content models:
        <!element foo (a|b|c|d|e|f)*>

        start_foo {
                InFoo == TRUE
        }
        
        start_a {
                if (InFoo == TRUE)                
                        .....
        }

An interface that allows events to occur in any old order leads to the
introduction of state variables
that control what events are valid and when. The state space gets very large
very quickly. For N boolean
state variables a program can be in 2**N possible states!

SGML/XML is a great way to reduce a state space because SGML/XML DTDs can be
usefully thought of as devices for imposing a time ordering on events. Take
something like
a simple bank account model:

<!element BankAccount (Open,Transactions,Close)>
<!attlist BankAccount Balance CDATA>
<!element Open,Close EMPTY>
<!element Transactions (Debit|Credit|Enquiry)*>
<!element Debit (FundsAvailable|FundsNotAvailable)>
...
This is both a concise piece of documentation about the goings on of these
BankAccounts and
a starting point for the implementation code. As events occur they are
"parsed" prior to the
real processing code thus checking the desired time ordering and obviating
the need for state
variables to do it in the processing code.

In Jackson, simple structure editors are used to create life histories which
quite frankly are
within a syntactic asses roar of DTDs.  A Jackson structure editor is a bit
like a DTD
editor except that processing code can be attached to all the nodes in the
DTD tree structure.

Case in point:
I used to write real-time financial trading systems for the PC in 80286
assembler(!). We used
a Jackson Editor to model the whole system and auto-generate the procedural
aspects of the
code from our life histories/data models. Before I left we have re-written
the whole thing
for Sun Workstations in Ansi C. The point? The life-histories, data models
did not change
only the implentation language.did.

Substitute "implemention language" for "formatting codes" in the above and
it sure
sounds like SGML.
Sean Mc Grath

sean at digitome.com
Digitome Electronic Publishing
http://www.digitome.com


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)