🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.text.sgml
Article #28

Re: SGML as Data Description

#28
From: Darrell Raymond
Date: Wed, 22 Jul 1992 12:56
68 lines
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!drraymon
References: <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