Re: Inline macros

[Sorry for leaving so much quote in, but it seems like important context...
David]

At 06:46 PM 4/25/96 -0500, Murray Altheim wrote:
>Paul Prescod <papresco@calum.csclub.uwaterloo.ca> writes:
>>At 01:40 PM 4/25/96 -0700, David Ornstein wrote:
>>>Is there some literal introduction character we could use (back tick or
>>>something) that would allow the lexer to simply gobble this stuff up into
>>>one big binary chunk?  This would allow something like:
>>>
>>><mimesection type=txt/x-funk>
>>>`%my(funcky, macro);
>>>more stuff in the funk language`
>>></mimesection>
>>
>>You are both trying to reinvent SGML marked CDATA sections. There is no need
>>to reinvent it. It does exactly what you are suggesting. Most SGMLers
>>consider it a Bad Idea to mix SGML and non-SGML data in the same file, but
>>if you want to do it, SGML already allows it.
>>
>> Paul Prescod
>
>And it's not syntactically ugly or complicated, won't make your palms hairy
>or anything. Given that HTML is *an application of SGML* it is already part
>of HTML. Because this feature is simply not available in *most* browsers
>doesn't make it invalid HTML. No need to reinvent anything here, folks:
>Just implement what is already there.
>
>('MSC' is SGML-eze for 'marked section close', which is ']]'.)
>
>    <![ CDATA [
>        -- any durned thing in here you want except MSC --
>    (This file must be converted with BinHex 4.0)
>    :$QeKBh"RF$)f-fNZFfPd!&0*9%46593K!*!$"d3&!*!%IHC6593K!!%!"d3&FNa
>    KG3)!N!3@!6!J)!TYB@0`Ch!b0M0T!*!9H(%!N!2$!-F"I`*E!*!$"J#3$iB!!!&
>    [...]
>    Jbkh-,Td[Yk!YN!#!))e3$p)+Iq9r0V!VQ5BUMqeJb5M[#*`lbHq-S(Y$L[m$!!!
>    K)3TYB@0`Ch!b0M0T!*!D``$(!Am#@`#3!`%!"cS6!*!(&J#3!iB!!!&Jrj!%!3#
>    Y66a3V9CI+`#3"3HIm`#3"3G$$`#3#MHF#mm!!!:
>    ]]>
>
>That's it. Not much of a barn burner. And legal, just not widely supported.

OK.  I get it.  I'm thinking about some server-side tools I'm building here...

>Oh, just read David O's latest message. MSC is not ']', rather ']]', so I
>don't think that's so much of an issue. 

If you mean that it's a fair bit safer because ]] is less likely to occur in
the data, this seems like a case of closeness in horseshoes and hand
grenades.  SGML doesn't give any useful help here with anything like an
escape character for the ']' does it?  You show the example above having
been BinHex'd which is cheating a bit.  If I wanted to, say, have a PERL
script in the marked section (roughly akin to the original intent in this
thread), what do I do if my script has a ']]' in it? (I do see your note
below about using an entity, but sometimes that wouldn't be done...)

>You mention describing a chunk --
>well, that can be done several ways. One way it could be done in
>'SGML-savvy HTML' (for lack of a better term) which would keep the SGML and
>non-SGML data distinct by declaring an entity that refers to your non-SGML
>data:
>
>  -- sample embedding ----
>
>    <!DOCTYPE HTML PUBLIC "-//Spyglass//DTD HTML 2.0 Extended//EN"
>                          "http://www.stonehand.com/dtd/html2x.dtd" [
>    <!ENTITY foo SYSTEM "http://www.stonehand.com/murray/foo.sit.hqx" >
>    ]>
>    <HTML>
>    <TITLE>Document Title</TITLE>
>    <BODY>
>    <P>Here's some embedded doodad: <![ CDATA [&foo;]]> </P>
>    </BODY>
>    </HTML>
>
>  ------------------------
>
>The 'SGML Bad Idea' (but still legal) would simply be putting the contents
>of 'foo.sit.hqx' in the place of '&foo;', which is what the processing
>system is doing anyway.
>
>Declaration subsets (the [part] after the PUBLIC and SYSTEM references in
>the above DOCTYPE declaration) are a common SGML structure. We just don't
>see them in this neck of the woods much.
>
>Murray
>
>```````````````````````````````````````````````````````````````````````````````
>     Murray Altheim, Program Manager
>     Spyglass, Inc., Cambridge, Massachusetts
>     email: <mailto:murray@spyglass.com>
>     http:  <http://www.stonehand.com/murray/murray.html>
>            "Give a monkey the tools and he'll eventually build a typewriter."
>
>
>

Received on Thursday, 25 April 1996 19:22:39 UTC