Re: Parameter entities vs. GI name groups

> From: Tim Bray <tbray@textuality.com>
 
> WG8-folk on the list; are we the only ones who would like a
> radical simplification of the PE replacement rules, or is this
> another pending-for-the-subset item?  How about another SGML
> Declaration option that says PEs are just string-substituted
> without regard for where they may be? -Tim

On this list about 2 months ago I proposed "pre-processing instructions" with  CPP delimiters and syntax.  (I chose CPP rather than
M4 because it is more well known, and because it is simpler.)

I don't know whether I was very clear, but my intuition was that "supply-side includes" (i.e. CPP pre-processing instructions) do
different things than "client-side includes" (i.e. XML entity references).  The "supply-side include" is a mechanism for document
maintenance and construction. The "server-side include" is a mechanism for minimisation (internal entities) and document
interrelations (external entities).

SGML86 has not needed this distinction, because it only has one locus of parsing.

However, I don't think this is an SGML matter: my pre-processing instruction really only declared the delimiters in the SGML
declaration for the sake of system documentation, not because the SGML parser used them.

I don't think XML should have CPP macros, or PEs.   A supplier can use CPP at their server to constuct their document: that is
simply a matter of storage management. Or they can use PEs at their end: I don't why the client needs PEs.

As to the question of whether WG8 folk are considering a radical simplification, the simplification has already been made!   You
want a macro-preprocessor that is independent of any SGML delimiters, Tim, I think.   This means that it cannot be invoked inside
XML, but must be invoked outside somehow.  

This is exactly the kind of issues that Formal System Identifiers (in the SGML Extended Facilities annex in new HyTime) deals with.
   FSIs are basically a way of adding inline attributes to links.  To give a rough example:
href="<archive type='tar' compress='pkzip'>ftp://ftp.me.com//pub/x.tar.zip"
The reason is, of course, that file extensions do not provide adequate type info when there are several competing products.  Tim,
would Netscape be interested in:
href="<file browser='communicator'>http://www.me.com/x.html">
which would allow a link to (hint to) select the program the link should be opened with?

In the particular case of CPP, you could  construct a link using something like:
	href="<file use='cpp'>x.h"
(ExFac people, don't flame about wrong keywords!)


Rick Jelliffe

Received on Saturday, 21 June 1997 01:26:10 UTC