I will attempt to locate a copy of the Dr. Dobb's Journal. In
case I don't, could you bring in your copy for perusal. The
beauty of XML lies in its ability to contain its own formatting
rules. However, I think at that point the author and I would
diverge sharply.
We have a major issue in software maintenance when it
comes to making changes on an optimum form. Not
infrequently the changes require a new optimum form. Just
as frequently this occurs as a global requirement effected by
a local change. In any case it involves a rewrite of logic, thus
a rewrite of source.
If you are willing to accept that logic programming works as it
does, transforming unordered input into ordered output,
compare that with imperative languages (first, second, and
third generation) which require "ordered" input or "logic in
programming". Logic programming doesn't "generate" code. It
organizes it. Effectively it rewrites the input every time into
output. This rewriting then due to changes in local logic
remains part and parcel of what logic programming expects to
do. That's how it works.
In logic programming then we have two equivalent forms of
source, one unordered, the other ordered. We only do
maintenance on the unordered form, affecting only local logic.
We depend upon the ordering process of the completeness
proof to provide the necessary and logically optimal, ordered
output. Compare this to the imperative languages which have
only ordered output as input to the next revision depending
upon a manual rewrite of the global logic.
In programming in order to reference data we have to
explicitly give it a name as part of data declaration. Prior to
structure programming with its frequent excess of "spagetti
code" constructed by an excessive use of GOTO statements
we had labels prefixed to every GOTO-targeted statement.
Since then statement labels have essentially disappeared
except for procedure names. The question becomes, "How do
we create names for statement-groups within procedures?"
"Ultimately how do we create names for individual statements
so that we can store them as source?"
The answer is, "We don't." We let the software do it. It's just
another clerical task we assign the software to save us the
effort. We let the software create content-based names, i.e.
based upon prefix textual data in the source statement. Say
we agree that it's 16 bytes. If the source is less than 16
bytes, we pad in on the right with blanks. And to this name
we append a 4-byte index value. The combination forms a
unique key for a row in a table in a relational database.
Now I would have to read the article on XML, but the
implication of an "XML file" implies ordered input, supporting
only manual revisions. Whereas in the system I propose, the
data repository/directory, we would have an ordered XML
output as a transformation of unordered input. In my system
the XML commands as source differ not one iota from any
other source text.
=====================================================
To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-programming".
For problems, contact the list owner at
"rollin@scoug.com".
=====================================================
>> Next Message >>
Return to [ 09 |
February |
2003 ]
The Southern California OS/2 User Group
P.O. Box 26904
Santa Ana, CA 92799-6904, USA
Copyright 2001 the Southern California OS/2 User Group. ALL RIGHTS
RESERVED.
SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group.
OS/2, Workplace Shell, and IBM are registered trademarks of International
Business Machines Corporation.
All other trademarks remain the property of their respective owners.
