Re: <insert> and external entity references

Daniel W. Connolly (connolly@beach.w3.org)
Sat, 06 Apr 1996 00:23:16 -0500


Message-Id: <m0u5QSy-0002UVC@beach.w3.org>
To: "C. M. Sperberg-McQueen" <cmsmcq@uic.edu>
Cc: www-html@w3.org
Subject: Re: <insert> and external entity references 
In-Reply-To: Your message of "Tue, 19 Mar 1996 11:23:06 CST."
             <9603191923.AA17113@www10.w3.org> 
Date: Sat, 06 Apr 1996 00:23:16 -0500
From: "Daniel W. Connolly" <connolly@beach.w3.org>

In message <9603191923.AA17113@www10.w3.org>, "C. M. Sperberg-McQueen" writes:
>Excuse me if someone explained this while I was not paying attention,
>but why are we talking about adding an INSERT tag with the semantics 'go
>find this file or document, and insert it here', when SGML already has
>the mechanisms needed for this, in the form of entity references?  Why
>not just start writing, requesting, or demanding HTTP servers that
>actually understand and process references to external entities
>as defined by ISO 8879?

So you're talking about doing this on the _server_ side, right?  Not
on the client (which is what I think most folks have been talking
about).

It seems to come down to performance, complexity, and expressive
capability.

My evidence that SGML external entity references are too
complese a solution is that I have proposed it a number of
times on comp.text.sgml, and I've had little luck getting
folks to understand the idea, let alone have a whack at coding it up.

[The idea boils down to using SGML entity reference syntax rather than
NCSA server-side-includes syntax, or any of the zillions of
other macro languages invented for this purpose.]

Regarding expressive capability: SGML enitities don't compose, and
don't take parameters. Granted, you can stick anything in a
system identifier, but selling:

	<!doctype html [
	<!entity r1 system "EVAL:row(1,2,3)">
	<!entity r1 system "EVAL:row(a,b,c)">
	<!entity t1 system "EVAL:table(&r1, &r2)">
	<!entity t2 system "EVAL:table(&r2, &r1)">
	]>
	... &t1 ...
	... &t2 ...


is tough, when the alternative (specialized macro languages)
don't require you to declare every macro call separate from
its usage.

As to performance: perhaps if sp were linked into the server
and not forked each time, it's performance would be bearable.
But I doubt it. It would be horrendously compute-intensive,compared
to something straightforward like m4.

And then we're back to complexity: sp is a HUGE pile of code,
if not in lines of code, then in complexity of that code.

sp isn't the only SGML parser, but YASP isn't much better,
and nobody's giving the really speedy ones away, cuz the
engineering required to get an SGML parser to be quick and
small is substantial.


>To illustrate, for those not yet conversant with all of SGML:  for
>this ...
>
>> Now, my serious question is, at this time could one simply use
>>
>> <insert
>>         data="http://www.mysite.com/path/file.html"
>> >
>> </insert>
>
>a normal SGML syntax would be this:
>
>1 in the document type definition,
>
>  <!DOCTYPE html PUBLIC "-//IETF//DTD HTML 2.0//EN" [
>  <!ENTITY myfile SYSTEM "http://www.mysite.com/path/file.html" >
>  ]>
>
>2 in the text itself,
>
>  &myfile;

<insert> is a client-side mechanism, but I
thought you were talking about server-side transclusion. Now
I'm confused.

I'm getting tired too. We really need a proper write-up of
transclusion links and all the discussion, proposals, and techniques
available.


>Is there an advantage to inventing a new notation for inclusion
>of documents and document fragments, rather than using the
>existing notation?  Or is it just not widely known that notation
>for such inclusion already exists and need only be adopted, instead
>of being invented?

After studying the issue for a few years, my conclusion is yes
on both counts.

Dan