Altova Mailing List Archives


Re: [xml-dev] The J2ME pseudo-XML botch

From: Daniel Veillard <veillard@------.--->
To: Mike Champion <mc@-------.--->
Date: 2/23/2003 9:52:00 PM
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/

Disclaimer

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.