Limitations on XML transported via XMPP
Problem: A conforming SVG viewer should be able to process internal and external DTD subsets, and make references to internal and external entities, as per the XML 1.0 specification, both of which are forbidden in XMPP, as per 1.1 of the proposed standard.
Possible solution: transport all SVG escaped
- up:
- it works...
- down:
- extra processing required before display.
- Ugly.
- Loose any advantages of inline XML.
- Need to parse a new document (SAX? XMLPull?) for every received stanza. Or come up with an UnescapingInputStream... the Ghetto mini-pattern.
Possible solution: forbid DTD & entity references in transported SVG.
- up:
- it's relatively easy
- down:
- while Batik is probably a "conforming SVG interpreter", putting Gradient in between it and the server stops the app as a whole from qualifying.
- Entities are defined as shortcuts all over the place in the SVG examples I've seen.
Possible solution:Allow only internal DTD with the DOCTYPE declaration - forbid inline <![CTDATA[]]> sections .
The remaining question then is what to do about the &entities; within the SVG sent over XMPP. These things could be anywhere.
S.3.a: I could put them as differently namespaced child elements... <gradient:attribute ref="amp"/>
...but I still can't accept entities referenced in attributes.
Chosen solution: Anything loaded via XMPP has DTD declarations, inline DTDs and entity references are forbidden.
However, if loaded via a location specified in the "src" attribute of the response via a different protocol (e.g. HTTP) then you can do what you want, as long as it's valid XML/SVG.
© 2006. Some rights reserved. Author: Ian Sollars.
