Altova Mailing List Archives

Re: [xml-dev] The subsetting has begun

From: Daniel Veillard <veillard@------.--->
To: Jon.Ellis@---.---
Date: 2/22/2003 10:15:00 AM
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 Veillard      | Red Hat Network
veillard@r...  | libxml GNOME XML XSLT toolkit | Rpmfind RPM search engine


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 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.