xml-dev - External entities in WF documents

[Peter Murray-Rust <peter@ursus.demon.co.uk>]

I have been developing some SVG examples [for my XTech2000 tutorial] and
run into a slightly unexpected problem with external entities. I have
raised this concern about entities - incautiously - on this list before and
agree that everything I am worried about is clearly stated in the XML 1.0
spec. So, very nervously, I confess I still have a problem...

I am using both IBM's SVGView (from Alphaworks) and Adobe's SVGView plugin
for browsers. Both are excellent tools and no criticism is intended. But
they behave differently...

I created a file like this (greatly simplified):

<!DOCTYPE svg SYSTEM "svg-19991203.dtd" [
<!ENTITY picture1 SYSTEM "picture1.ent">
<!ENTITY picture2 SYSTEM "picture2.ent">
]>
<svg>
<!-- ... -->
&picture1;
<!-- ... -->
&picture2;
</svg>

Running this with SVGView-IBM renders the expected result (even if
svg-19991203.dtd is absent). Clearly SVGView-IBM expands external entities
whether or not a DTD is present. [I do not know if it hardcodes a DTD and
validates, or whether its default WF behaviour is to expand entities.] By
contrast SVGView-Adobe does not include external entities and the rendering
is apparently "broken". If I explicitly expand the entities to text within
the internal subset SVGView-Adobe renders the picture perfectly.

Both tools are behaving "correctly" as far as the spec is concerned. A
parser can expand or ignore external entities in WF documents. But I don't
think the behaviour is acceptable to the world in general. It's clear to me
that someone needs to modify their behaviour. It could be:

	authors of SVG should never use external entities
	SVG engines should throw explicit warnings to viewers warning that bits of
the picture will be missing
	SVG engines should expand all external entities.
	the SVG community needs to address this problem
	PM-R should shut up because the current state is perfectly acceptable

Now for "SVG" read "XML" and modify the text to include any engine with an
XML parser (maths, chemistry, purchase orders, etc.). It's clear that
unpredictable parser behaviour will cause serious problems. If
manufacturers have this latitude then I belive we need some or all of:
		labels on XML engines stating precisely what (legal) range of behaviours
can be expected
		ability to modify behaviour (legally) through commandline or window.


P.


***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/threads.html
***************************************************************************