[
Lists Home |
Date Index |
Thread Index
]
>Again, the problem is that it creates yet another maybe fatal, maybe
>not error which reduces interoperability. THere doe snot appear to
>be any ambiguity about this in the current spec. A change here is
>unjustified and unnecessary. Parsers that do not correctly implement
>this requirement are nonconformant and should be fixed. That's all.
Suppose we have
<!ENTITY foo "&bar;">
The reason this is a problem is that when the entity value for foo is
read, the referred-to entity bar may not yet be defined, so the parser
cannot tell whether it is parsed or unparsed.
To "fix" this is midly tedious; parsers could be changed to keep a
list of entities referred to in entity values, and check that they
aren't unparsed when they are eventually defined. XML doesn't require
this sort of thing in most analogous cases but rather allows the
parser to just make a single pass: for example, if bar is undefined,
there is no error, and entity references in attribute defaults cannot
be forward references at all.
If the entity foo is ever *used*, the error will be detected then
(as it will be if bar is undefined).
So I think the natural thing would be to have "bypassed" instead of
"forbidden", but since existing implementations varied - most but not
all of the ones we checked treated it as "bypassed" - we changed it to
"error".
-- Richard
|
