Re: EMBED (Re: HTML 2.0 specification)
Terry Allen <terry@ora.com>
Date: Fri, 2 Sep 94 17:22:19 EDT
Message-id: <199409022120.OAA19110@rock>
Reply-To: terry@ora.com
Originator: html-wg@oclc.org
Sender: html-wg@oclc.org
Precedence: bulk
From: Terry Allen <terry@ora.com>
To: Multiple recipients of list <html-wg@oclc.org>
Subject: Re: EMBED (Re: HTML 2.0 specification)
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-Comment: HTML Working Group (Private)
| About embed -- compare the NOTATION facility in SGML.
| It's imortant that you don't break SGML conformance, or, if you do, that
| it is a conscious decision. You can't simply embed arbitrary data,
| although if it is encoded in an SGML-safe way that's acceptable.
| E.g. you have to watch out for </ occurring in it.
The MIME type ought to take care of NOTATION issues; that is,
the MIME type should be mapped to the appropriate NOTATION if
need be. The arbitrary data need not be parsed; you could insert it
the rendering stage, after the parse, although if the content
turned out to be SGML you'd have to start a new parse (as though
it were a SUBDOC) and insert the rendered contents of that
second parse.
It is true that if arbitrary characters are dumped into an
element (even a CDATA one) and </ occurs there will be a parsing error.
One could get around this by inserting CDATA marked section
delimiters around EMBEDded data:
<p>foo
<![ CDATA [
this is some </test text
]]>
end of para.</p>
This does not work if the CDATA marked section occurs in a
CDATA element, I learn by experiment.
--
Terry Allen (terry@ora.com) Editor, Digital Media Group
O'Reilly & Associates, Inc. Sebastopol, Calif., 95472