Article View: comp.text.sgml
Article #28Re: SGML as Data Description
From: Darrell Raymond
Date: Wed, 22 Jul 1992 12:56
Date: Wed, 22 Jul 1992 12:56
68 lines
3802 bytes
3802 bytes
In article <9207212241.AA03094@ucbvax.Berkeley.EDU>, DRMACRO@RALVM13.VNET.IBM.COM ("Dr. "Eliot Kimber" Macro") writes:
>I'm really confused by the question "could markup be eliminated?".
>Maybe I'm being dense (wouldn't be the first time), but I fail
>to see the point in this question. It would sort of be like
>asking highway engineers if roads could be eliminated because
>airplanes are so much more efficient methods of transportation.
>The question falls outside the parameters of the current problem,
>and thus is meaningless, at least to highway engineers.
>The whole value of markup is that it provides information about
>the data that is not intrinsic in the data itself. Ipso facto,
>it can't be eliminated.
Let's sharpen up the analogy a bit. It would be more like asking
if road signage could be eliminated, under the condition that I
supply every vehicle with a computer that can be used to determine
where it is. Certainly "the whole value of signs" is that they
provide information that is not intrinsic in the road system itself,
but on the other hand, if I can provide the information in some other
way, signs can be eliminated.
Now, given that signs are not indispensable, it becomes reasonable
to ask how the fundamental properties of signs affect the way they
present information. Consider for instance:
1. You can't have too many signs, because then they start to
get in each others' way (i.e., if you have too many tags
they may interact in funny ways, or just expand the text
too much).
2. Signs can't be put just anywhere; you have to put them on some
public property (i.e., if you start dropping tags into the
middle of words, you affect some other properties of the text,
such as searches with grep).
3. If you take a taxi to the middle of the city, and don't watch
the signs, you don't know where you are (i.e., signs appear
at boundaries, and not at every point within the region they
define).
4. Signs may be torn down or turned around by vandals
(i.e., someone can use a text editor to modify a few
tags in the document).
Now before someone writes back explaining in great detail why these
aren't really problems, let me remind you that it is just an analogy,
intended to cure Eliot's confusion. Tags are not road signs, so
arguments that road signs are very important, etc. will prove nothing
about markup.
>Perhaps it would be helpful to explain for non-scientists like
>myself the meaningful difference between context free and
>recursively enumerable?
Recursively enumerable means a language whose acceptance requires a
Turing machine. Context-free means a language whose acceptance only
requires a pushdown automaton. Pushdown automata are, as a class,
significantly less powerful than Turing machines.
If you can express a relationship within the content model of SGML,
the relationship is at most context-free. If the relationship can't
be expressed within the content model of SGML, it is more than
context-free, and may be as "bad" as recursively enumerable.
The meaningful difference is this: anything that you want to express
that requires recursive enumerability is (insofar as I am aware) neither
captured nor enforced by SGML.
-Darrell.
Technical Details
Message-ID:
<BrsJys.661@watdragon.waterloo.edu>Path:
arc1-ca.pugleaf.net!sparky!uunet!zaphod.mps.ohio-state.edu!cs.utexas.edu!torn!watserv1!watdragon.waterloo.edu!drraymonReferences:
<9207212241.AA03094@ucbvax.Berkeley.EDU>Show Full Headers
Complete Article Headers
Newsgroups: comp.text.sgml Path: arc1-ca.pugleaf.net!sparky!uunet!zaphod.mps.ohio-state.edu!cs.utexas.edu!torn!watserv1!watdragon.waterloo.edu!drraymon From: drraymon@watdragon.waterloo.edu (Darrell Raymond) Subject: Re: SGML as Data Description Message-ID: <BrsJys.661@watdragon.waterloo.edu> Organization: University of Waterloo References: <9207212241.AA03094@ucbvax.Berkeley.EDU> Date: Wed, 22 Jul 1992 12:56:51 GMT Lines: 68