Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: The J2ME pseudo-XML botch
 On Sun, Feb 23, 2003 at 04:26:01PM -0500, Mike Champion wrote: > On Sun, 23 Feb 2003 16:10:05 -0500, Daniel Veillard <veillard@r...> > wrote: > > > > The kind of interop problem likely to happen due to J2ME decision > > is really orders of magnitude larger than the XML Namespace induced > > subsetting, heck it won't even allow to parse correct XHTML which > > requires the DOCTYPE presence, > > Are you (and Elliotte Harold?) saying that if the J2ME folks were to change > the spec and allow DOCTYPE declarations, but not implement all the > productions required to process an internal subset, then the J2ME "XML" > processor would be much more suitable even if it is not a fully conformant > XML 1.x implementation? I'll guess that they would find that a > constructive suggestion. It would seem to meet their needs for a minimal > footprint while meeting the community's need to process "real" XML > documents on J2ME environments. They were worried about problems where > failing to choke on DOCTYPE declarations would raise expectations that > entities are declared, default attribute values set, and so on, but (on > reflection, wearing my potential J2ME user hat) I would prefer that to > rejecting all XHTML documents! I would not endorse myself the suggestion of implementing anything outside the "well formed" level of conformance of XML-1.0 . Failing on DOCTYPE makes it just obvious it's not an XML parser. I still 100% think it's a framework problem. I think SAX has serious control limitations (and is an horrible processing model to suggest to most programmers, but it's another rant) basically the default processing model should be conformant to XML-1.0, I don't think the code footprint argument holds as Tim Bray expressed clearly, but if people are really afraid of entity expansion they should be able to control them. I would feel far far more comfortable with a parser correct by default but which could be controlled at runtime to possibly limit some operations. I can't agree with a decision which is IMHO a bad handling of engineering constraints, those being runtime checks, the idea of burning in hardware or ROMs limited parser while stating they are the processing engine for XML on that platform simply make me sick, sorry. But allowing through APIs to reduce that capability for custom processing is acceptable. http://java.sun.com/products/cdc/ "Typically, these devices run a 32-bit microprocessor/controller and have more than 2.0MB of total memory for the storage of the virtual machine and libraries." If they can't put a parser limited to well formedness in this including the internal subset DOCTYPE well they have some design problems, sorry ... Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@r... | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ 
|
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
|
|||||||||
