[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] External entities in WF documents
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@x...&BODY=unsubscribe%20xml-dev List archives are available at http://xml.org/archives/xml-dev/threads.html ***************************************************************************
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|