Lists Home |
Date Index |
- From: John Cowan <email@example.com>
- To: firstname.lastname@example.org
- Date: Mon, 21 Sep 1998 14:10:09 -0400 (EDT)
Paul Grosso scripsit:
> I'm not understanding why OVERRIDE NO doesn't make sense. Perhaps
> I'm missing something about SAX or your implementation. (Assume I
> understand TR9401, since I edited it.)
Ah, good. Perhaps it is I who does not understand. If so, please
I quote James Clark's docs, since they are pretty clear:
# A PUBLIC, ENTITY, DOCTYPE, LINKTYPE, or NOTATION entry
# with an overriding mode of YES will be used whether or not the
# external identifier has an explicit system identifier;
# those with an overriding mode of NO will be ignored if external identifier
# has an explicit system identifier.
In the XML context, as I said, every external identifier has
an explicit system identifier (with the minor exception of
notation declarations). Therefore, any entries with an
overriding mode of NO will be unconditionally ignored. Since this
is the default, any catalog not beginning with OVERRIDE YES will
be ignored *in toto* (except for SYSTEM entries).
This seems less than sensible.
> I don't understand what the problem is, and I don't understand how--if
> there really is a problem--anything about XML makes it a problem that
> isn't a problem with SGML in general (XML is SGML, you know).
XML documents are SGML documents, but XML is not SGML, because of the
additional constraints it imposes. All XML system ids are URLs, and
in general are to be taken at face value. SYSTEM entries serve as a
private URL-URL mapping scheme, but must the whole of a public-id-
resolution infrastructure be searched for each and every URL referred
to in a XML document?
XML, unlike SGML, has the Web as its implicit background.
John Cowan email@example.com
e'osai ko sarji la lojban.
xml-dev: A list for W3C XML Developers. To post, mailto:firstname.lastname@example.org
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:email@example.com the following message;
To subscribe to the digests, mailto:firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (mailto:email@example.com)