[
Lists Home |
Date Index |
Thread Index
]
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@redhat.com>
> 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@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
|
