W3C home > Mailing lists > Public > w3c-sgml-wg@w3.org > October 1996

Re: A17: keep or drop entities?

From: Eve L. Maler <elm@arbortext.com>
Date: Fri, 11 Oct 1996 09:32:26 -0400
Message-Id: <>
To: DAVEP@acm.org, Charles@sgmlsource.com
Cc: W3C-SGML-WG@w3.org
At 10:35 PM 10/10/96 -0500, DAVEP@acm.org wrote:
>There may have been just two principal purposes, but there is certainly
>a third in this day and age:  When one is inserting an ordinary text entity,
>the replacement text is specifically intended to become characters in the
>document.  When "&amp;" is inserted in a document, one does not normally
>intend it to be the same as though "[amp   ]" were directly in the document.
>Many processors rely on the SDATA designation to trigger the special
>handling.  Leave it out and we're in trouble.

Yes, this is exactly what I meant.  One way or another, you need the
effect of saying "This is an instruction to the system to return
something else."  There are three main ways it gets used:

o Trivial keyboardable cases (lt, amp, sometimes gt) to escape markup
  characters.  These can be replaced with CDATA or text entities.

  (Of course, "keyboardable" depends on your keyboard!)

o Nonkeyboardable cases.  Maybe these can be replaced with character
  references of one kind or another.  I get too lost in the UNICODE
  jungle to really understand this alternative, but I could be 

o Non-special-symbol cases, where you're truly sending out to the
  system for some processing to happen and some value to be returned
  -- for example, "insert the current date and time here".  Should
  this be done exclusively with non-SGML scripts instead?

As Dave and Rick point out, many systems -- ADEPT is one of them, by 
the way -- key off the SDATA label to access an external table.
If all documents potentially need the functionality of looking 
something up outside on the system, why not stick with SDATA and
avoid making all applications reinvent this wheel?

Received on Friday, 11 October 1996 09:29:37 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:25:04 UTC