🚀 go-pugleaf

In article <23320F@erik.naggum.no>, SGML@ifi.uio.no (Erik Naggum) writes:
|> I see nothing in the standard which precludes having entities whose
|> entity text has different values each time it's referenced.  However,
|> I also see nothing in the standard which says that the entity manager
|> is not allowed to cache the entity text, but must access the physical
|> storage of the entity each time.  In fact, a pretty good case can be
|> made for requiring entity texts to be static with respect to an
|> invocation of the parser.
|> 
|> 4.13 SDIF unpacker:  A program that decomposes an SDIF data stream into
|>      its constituent entities.
|> 
|>      NOTE -- If necessary, the SDIF unpacker will modify the system
|> 	  identifiers of markup declarations to be consistent with
|> 	  storage addresses in its environment.
|> 
	It is interesting to note that given the current standard,
	use of SDIF restricts the flexibility of SGML external
	entities pointed out in the first paragraph.

	The restriction with SDIF arises as follows: SDIF scans an
	SGML document, retrieves the "current" content of each
	external entity and produces a formatted data stream that
	contains the document, the external entity contents and a
	"table of contents" mapping the entity contents to external
	names.  Note that the mapping is such that there is a
	many-to-one mapping between external name reference and
	content; hence, as noted in the first paragraph "... entity
	texts are static with respect to an invocation of ..."
	the SDIF application.

	SDIF "externalizes" the mapping function of SGML entity
	managers, providing in effect a portable entity manager.
	The caveat is that some SGML flexibility is lost, in that
	ported entity content is no longer capable of, as noted
	from paragraph one, "having different values each time it
	is referenced".  For example, a legitimate SGML entity is
	a random number server process that returns a random integer
	for each reference.  When packed by SDIF, each declaration to
	this entity by an SGML document will point to a single
	content instance (all references point to the same number,
	for this example).  Hence, when unpacked and parsed,
	the SGML document will NOT show random numbers!

	External entity portablity is a tough issue, and the SDIF
	solution is an unsatisfying compromise between feasability
	and desirabilty.  In the above example,
	what is desired is some means of migrating the entity
	(process) that generates content, rather that an instance
	of the content.	This area clearly should be reviewed by the
	SGML standards committee, although perhaps no better
	alternative will emerge, though Object Request Broker
	technology should be influential in this area.
jpl