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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: Entities and non-validation

[ Lists Home | Date Index | Thread Index ]
  • From: David Brownell <david-b@pacbell.net>
  • To: Shawn Silverman <shawn@activated.com>
  • Date: Tue, 02 Nov 1999 10:56:14 -0800

Shawn Silverman wrote:
> 
> How should non-validating parsers handle undeclared:
> 
>         1) Parameter entities in the DTD

If you look at the grammar production, it has only a [VC]
next to it, so this is only a validity error -- which a
nonvalidating processor really ought to ignore, beyond
setting a flag so it ignores all further declarations.


>         2) General entities in the DTD

For refs within entity declarations:  ignore them unless
(and until!) that undeclared entity is later referenced
by expanding the replacement text of the declared entity.
Such an actual reference violates a WFC.

For refs within attribute defaults:  violates one
of the clauses in [WFC: Entity Declared].  But that
WFC violation should be ignored if "standalone='no'"
and (!) the processor didn't read some external PEs.

(I find those two "Entity Declared" clauses to be one
of the most confusing, if not ambiguous, parts of the
whole XML spec.) 


>         3) General entities in the document

Violates a WFC -- fatal error, full stop.


> I like to qualify my question by stating that it is assumed that all of
> these entities are used appropriately, ie. PE's only in the DTD, GE's
> inside attribute values and content, etc.
> 
> I am under the impression that if standalone='no' for the document that
> a non-validating parser can assume that all undeclared entities are
> external.  Is this correct?

If it didn't read those entities, it can assume all sorts of
things going on there, yes.  But if it does read the entities,
then it knows the truth and shouldn't assume otherwise.


> My second question is similar, and comes from section 4.4.3, "Included
> If Validating".
> 
> The first paragraph states that:
> 
> "When an XML processor recognizes a reference to a parsed entity, in
> order to validate the document, the processor must include its
> replacement text. If the entity is external, and the processor is not
> attempting to validate the XML document, the processor may, but need
> not, include the entity's replacement text. If a non-validating parser
> does not include the replacement text, it must inform the application
> that it recognized, but did not read, the entity."
> 
>         1) Obviously, the parser can tell if the entity is external if it has
> previously been declared.  But what if it has't?  What should a
> non-validating parser do?

The simple answer is to stick to non-validating parsers which DO read
all external entities, but that may not be practical.

Otherwise, I'd say the answer is application-specific.  I think
XHTML says things like "render the reference", but that's not
useful for all other applications.


>         2) How does the parser "inform the application" via the SAX interface?
> Is this through the EntityResolver interface?

Good question.  My stance is that SAX2 solves this generically, by
exposing whether _all_ external general entities are included, or not.
And having a lexical callback to indicate the start/end of entities;
the app can have recorded the declarations.

Given that, no per-entity call is needed.  (SAX 1.0 doesn't have any
way to expose this.  Returning null from EntityResolver.resolveEntity
says the parser should use the SYSTEM identifier.)


Those are good questions in some messy areas of XML processing.

- Dave

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