OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: external parsed entites (was: A unique ID question ?)

[ Lists Home | Date Index | Thread Index ]
  • From: Paul Prescod <paul@prescod.net>
  • To: "Steven R. Newcomb" <srn@techno.com>
  • Date: Mon, 08 Nov 1999 09:31:23 -0600

"Steven R. Newcomb" wrote:
> ... 
> However, reality intrudes.  Most information is architected
> suboptimally.  I think it would be a mistake to discard external
> parsed entities.  I think XML needs to have features that let people
> do silly things (like evilly putting all the documentation of a
> weapons system into a single 190,000-page document) without causing
> every XML application to blow a gasket.  

Just about every XML application will blow a gasket with or without
external parsed entities. The "applications" that external parsed
entities help are file transmission and storage applications: browsers,
file transfer engines and file systems. These software components
typically have MUCH GREATER CAPACITIES than the applications that work
with the XML logical structure. With all due respect, I feel more
comfortable using FTP to transfer a 1 GB document than I would stuffing
that into Excelon, Internet Explorer, an XSLT engine or anything else
that works with the logical model (other than SAX).

> We need the means to permit
> evil to exist in order to avoid creating a worse evil: the perception
> that XML is insufficiently robust to handle real situations, no matter
> how evil they are.

XML tools *are* insufficiently robust and external entities in no way
help to alleviate that problem. If anything, they make the problem worse
by encouraging people to make their XML documents larger than tools can
handle. A component approach is much safer.

On the other hand, while I agree with Eliot that external entities are
more hassle than they are worth, they are occasionally useful on
smallish problems where you can manage the ID namespace manually and
want separate editing of chapters etc. In other words, since we have
them one shouldn't avoid them supersitiously. Just learn what they are
good for (small, hand-maintained projects) and not good for (large scale
component reuse). If I could take them out, I would though.

 Paul Prescod  - ISOGEN Consulting Engineer speaking for himself

"No religious test shall ever be required as a qualification to any
office, or public trust, in this State; nor shall any one be
excluded from holding office on account of his religious sentiments,
provided he acknowledge the existence of a Supreme Being."
                         - Texas Constitution, Article 1, Section 4

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS