On Sat, Feb 22, 2003 at 09:56:02AM +0800, Jon.Ellis@S... wrote:
> The footprint requirements just don't appear allow it. There are more productions to process the DTD than the XML document, and that's before you have to deal with what you find there.
> 
> As always, we'd be happen to be proved wrong. Given a way to be fully compliant, within the limitations of the devices, we would use it. The EG spent quite some time looking for such a solution...

  Can you state clearly what are your constraints in term:
    - of memory usage for Code, static data
    - of maximum memory and CPU use per instance processing
    - of average memory usage w.r.t. instance processing
    - of average CPU usage w.r.t. instance processing

in the 2 last point using typical examples could be a good idea.
Once the data are on the table then it's possible to give a
realistic answer to whether subsetting XML was the necessary
evil for this.
My guts feeling is that your problem is a framework one not a
problem with the XML spec purely and to be perfectly frank the
reliance on Java just makes the 2 of the 4 points I just pointed 
out insanely large. Still it's not a valid justification to 
blatantly break a well established specification.
Fix your parsers/framework instead of tweaking the spec to 
get the overall solution to fit your constraints :-(

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/