Hi, Dick, Kemp, and all,
I'll be the first to agree that Ted Nelson is a very bright guy, and
a real
visionary, but sometimes visionaries overstate their case to make a
point,
or miss something that doesn't quite match their vision.
[EMAIL PROTECTED] wrote:
>
> I vote for Kemp's thoughts.
> HTML and XML are merely contrived formats (wrappers).
>
But, as one writer put it, "When I talk to you, I gotta use words!"
If
I'm gonna send data from point A to point B, I gotta use *some*
format...
WIDR, I don't think HTML and XML belong in the same sentence. HTML
is a
conceptual hash of:
- a particular viewpoint of a common logical structure for text
documents,
- a heavy overlay of other viewpoints of how to mish non-text
content into
the overall mash, and
- an amalgam of presentation-oriented hints which assume that the
resulting
stew will be viewed by a human being on an arbitrarily long piece
of
virtual scrolling paper.
OTOH, XML is a meta-language and culture that include:
- notation(s) for allowing one to design specific
formats/representations
for particular classes of data, and
- a preference for representing *a* hierarchical semantic
structure, rather
than presentation formatting.
Unfortunately, there's so much hype about XML replacing (or being
translated
into) HTML via a bunch of other Xacronyms that the distinctions
above are
candidates for endangered species of the month. ;-)
IMHO, the interesting issue with XML is as a counterbalance to ASN-1
(Unicode
text instead of bit-level binary), so that:
- XML is human-readable (and writable, if one is e.g. creating test
data
or small chunks of content),
- XML is *F*A*R* easier to encode/decode,
- ASN-1 takes way less bandwidth.
>
> > I too have a major problem with HTML and XML heirarchical structure - it's
> > not the way most things work.
>
I never thought of as XML representing "the way things work", but
just as
a flexible notation for sending a description of a thing from point
A to
point B (in space *or* time). It's an encoding.
>
> >
> > What we are doing is cramming arbitarily-structured information into a
> > predefined heirarchy. What we should be doing is assigning appropriate
> > structures to the information as required by (a) the intrinsic structure of
> > the content, (b) the relationship between the information and the
> > application, and ((c) the structure of the application itself. All 3 are
> > different and should be separable, and NONE of them are always heirarchical.
> >
>
We could get into *major* philosophical wars over that paragraph!
;-)
I suggest that the activity of programming involves at least the
following
four structures:
1) a conceptual structure of the class of problems under
consideration,
2) a representational (e.g. data) structure for a specific instance
of
the problem class,
3) a textual structure (source code) for a solution to the problem,
and
4) a dynamic structure of events that occur as a computer performs
the
solution of an instance of the problem class.
AFAIAC, all of "structured programming" boils down to an approach
that
pursues harmony among those four structures. As a trivial example,
figuring
the average of a collection of grades, can be viewed as:
1) thinking of the collection as an iteration of (occurrences of)
the
concept of "grade" [the conceptual structure];
2) choosing to represent the collection as:
2a) a file (iteration of lines with one grade each), or
2b) an array (positional iteration of grade data), or
... some other iterative structure [the representational
structure];
3) having a notation to indicate clearly and succinctly that each
individual
grade should be added into the total [the textual structure],
and
4) expecting the computer to "repeat" the operation of "add this
one also"
for as many instances as appropriate [the dynamic structure].
As a result, I'd rather be able to write something like
total: 0.0
foreach grade gradeblock [total: total + grade]
average: total / length? gradelist
than the (commonly used when the "structured programming" issue was
first
unleashed on the world) more primitive
100 let t = 0
110 let i = 1
120 if g(i) = -1 then 160
130 let t = t + g(i)
l40 let i = i + 1
150 goto 120
160 let a = t / i
because the text doesn't contain any single/simple/unambiguous
"thing"
that indicates repetition/iteration. Harmony among structures is A
Good
Thing IMHO.
That said, I was careful above to keep saying "a ... structure"
rather
than "the ... structure" because most non-trivial problems can be
thought
about in more than one way, and it's only to be expected that two
people
who think about a problem in different ways will develop different
structures for their representations, program text, and execution
events.
average (L) = avg (L, 0, 0).
avg ([], t, n) = t / n.
avg ([g | r], t, n) = avg (r, t + g, n + 1)
Anytime we communicate an instance of a concept from point A to
point B
we must cram it into some arbitrary notation/format for transport
and/or
storage. We should be careful not to think that the
transport/storage
format must rule what we do with the idea before encoding or after
decoding. For example, to send you the content of a two-dimensional
data structure, I could:
- send each row as a line, with commas between elements in
consecutive
columns;
- send each column as a line, with commas between elements in
consecutive
rows;
- send each element on a line by itself, as a triplet of row#,
col#, value;
...
and the list goes on. Each of these is better for some kinds of
pre- and/or
post-transfer processes, and worse for some others. But if I want
the two
sides of the transfer to be as independent of each other as
possible, then
I'm likely to end up using an arbitrarily-structured representation,
and
viewing the cost of encoding and decoding as just the cost of the
flexibility
of swapping out processes at either end without affecting the other.
For my money, most content does not have "intrinsic" structure. I
simply
choose a structure for it based on my own background, training,
experience,
and thought patterns. Someone else might very well "see" the
content as
as having an entirely different structure. If we're going to
exchange it
(especially without first requiring one of us to adopt the other's
mental
model in toto) we just have to find an arbitrary representation
to/from
which we can both translate our internal conceptual structures.
So much meta-programming, so little time... ;-)
-jn-
--
Extensive studies have shown that 93% of all statistics are
meaningless.
-- Richard Hartman
joel&FIX&PUNCTUATION&dot&neely&at&fedex&dot&com
--
To unsubscribe from this list, please send an email to
[EMAIL PROTECTED] with "unsubscribe" in the
subject, without the quotes.
