Terry Allen (
Thu, 29 Jun 95 17:16:43 EDT

Glenn re Terry:
| But, as has been mentioned, we have shied away from requiring UAs to
| read an internal subset, because then authors can put anything in
| there (ISO 12083, etc). So this is not the best way forward.
| I don't agree. First, a document containing an internal subset is not
| currently unconformant. Therefore UAs should be prepared to deal with
| internal subsets now. The question is how much.

I'd be happy if they did. But it would be a very large change.

| We can establish an HTML application convention that sanctions the
| interpretation of only certain declarations and ignores others.

Yes, I agree that in principle we can. However, your example

<!NOTATION MyNotation PUBLIC "-//MyOrg//NOTATION MyNotation//EN">
<!ENTITY MyRandomData SYSTEM "" NDATA MyNotation>

suggests that the convention would be "attend to notation and entity
declarations, but ignore element declarations."

I don't have any SGML tools that will do that (so far as I know),
but at the moment I can vet all my docs with my SGML tools. I don't
want that to change.

| I would
| think this is a much preferable route to follow than inventing new
| mechanisms and new incompatibilities. If SGML provides the mechanism,
| then we should use it if at all possible rather than inventing a new
| mechanism.

I don't understand "new mechanisms." There is an SGML solution: a change
to the content model and attlist of META. It would result in some
backward incompatibility, but that incompatibility would be minor and
easily remedied (I think; perhaps some of the users of META would
tell us?).

I don't insist on such a change, I just present it as the most
straightforward solution. If it won't work, Murray's suggestion
to link out to [what would constitute an URC, btw] a separate doc
is much less painful than trying to break off part of the functionality
of the SGML internal subset. Isn't it?


Terry Allen  (   O'Reilly & Associates, Inc.
Editor, Digital Media Group    101 Morris St.
			       Sebastopol, Calif., 95472

A Davenport Group sponsor. For information on the Davenport Group see or