[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Invalid Markup in External DTD conditionals

  • From: "C. M. Sperberg-McQueen" <cmsmcq@blackmesatech.com>
  • To: Daniel Murphy <daniel@devasta.ie>
  • Date: Mon, 24 Jul 2023 20:26:26 -0600

Re:  Invalid Markup in External DTD conditionals
Daniel Murphy <daniel@devasta.ie> writes:

> ...
> My question is: Why is the ignore section not expected to be valid
> declarations like an <![INCLUDE[]]> section? I mean, if you have to
> check the IgnoreSection of a DTD anyway to ensure that the <![ and ]]>
> are all correct, it seems a bit of a waste to have to implement
> dedicated parsing rules for something you are going to be discarding
> regardless. Is this a holdover from SGML? Or was there some other
> motiviation?
>
> Just curiosity really; would be interested to learn more about XMLs history.

I have not consulted the decision records or the discussions of the
working group, so what I am about to say may be wrong as a historical
account of the design motivation.  But:

(a) The grammar for ignoreSectContents is a lot smaller and a lot
simpler than the grammar for extSubset, which is what you'd need if you
wanted to require that an ignored marked section consisted of
syntactically correct declarations.  If the only thing you are doing is
scanning an external subset looking for entity declarations, doing the
work of parsing all the declarations in the ignored subset would have a
very high cost to benefit ratio, even if doing so did not involve a lot
of entity expansions.

(b) One possible reason for marking a marked section with IGNORE is that
there is some syntax problem in the section which you have not yet
resolved; if the contents of the marked section were required to be
syntactically correct, you could not make the parser skip over that
problem except by commenting it out (error prone since comments don't
nest) or by deleting it entirely (possible, but not really the best
approach).

(c) Yes, ISO 8879 does provide that the only thing matched within an
ignored marked section are the beginnings and endings of marked
sections, so at least part of the motivation for the design is
compatibility with 8879.  And if memory serves I think there were at
least some in the group who felt that 8879 was right not to require
parsing of the content of ignored sections, beyond the minimum needed to
locate the correct ending delimiter.

If you want historically reliable information on the thinking in the WG,
I recommend reviewing the relevant threads in the mail archive at

  https://lists.w3.org/Archives/Public/w3c-sgml-wg/

but locating those threads will not necessarily be simple.  The
discussions I have located relate to the questions labeled A.6, A.7, and
A.8, all discussed in October 1996, but there may well be other
discussions later.

I hope this helps.

-- 
C. M. Sperberg-McQueen
Black Mesa Technologies LLC
http://blackmesatech.com


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.