Re: A8: INCLUDE/IGNORE marked sections?

At 03:38 PM 10/4/96 CDT, Michael Sperberg-McQueen wrote:
>But marked sections are used in prologs, too, not just instances.

I don't see any need for INCLUDE/IGNORE marked sections in instances, but
some form of conditional inclusion/exclusion needs to be retained in
DTDs.

>  - If we're worried about the load on browsers and other software that
>wants to be lightweight, we can define a subset of the C preprocessor
>into the language and say servers should support #ifdef and #ifndef and
>maybe #if, but that clients need not.

If we do allow conditional processing in declarations, I think we should
also define a nice clear method for implementing it. Since the client
is likely to "pull" the DTD, it'll need to know how to ask for the
"right" DTD. There are a lot of ways you could kludge this, but I think
we should have a defined method. I hate to say it, but one of the
difficulties of SGML conprehension and acceptance is that there are no
"set" ways of doing things--you can really do most anything you want.
It's hard for some to swallow and uncomfortable for others.

>(A server/client distinction in the language has been suggested before,
>but not extensively discussed.  One of the design goals suggests we
>want to avoid such divisions, but accepting it may be better than
>having a language too heavy for lightweight processors but not strong
>enough for real work.  I don't know the best answer.)

I still kind'a like the idea, since you could have really lightweight
processors on the clients which is where you really want light weight.
This would allow us to put more into the really useful stuff on the
client-side when we get to linking and the like. This is where we can
make a real distinction between HTML and XML.

Server-side XML could really be just a codification of SGML as is
currently implemented in most systems. It's the stuff that we've pretty
much put to rest already that causes much of the discomfort with
SGML.

bob


Robert Streich				streich@slb.com
Schlumberger				voice: 1 512 331 3318
Austin Research				fax:   1 512 331 3760

Received on Wednesday, 9 October 1996 03:06:41 UTC