Re: Is inclusion stable?

On Tue, Jan 27, 2004 at 11:40:21AM -0500, Elliotte Rusty Harold wrote:
> At 11:58 AM +0100 1/27/04, Daniel Veillard wrote:
> 
> >  Well that question is not answered in the XML specification either,
> >I don't see why XInclude should. In XML as far as I remember there
> >is nowhere specified that referencing multiple time an external
> >parsed entity, the same content should be used each time. This
> >is implementation dependant at the XML level (though I bet all
> >implementations reuse the same content for the resource), and I think
> >it would be stange to require this at the XInclude level (though
> >again I would expect nost implementations to reuse the same content
> >for the resource). But I could see case where XInclude processors
> >operating in embedded systems would give more weight to memory
> >consumption than processing costs and no do caching in such an
> >environment. IMHO it's better left an implementation choice.
> 
> I certainly don't think it's obvious that implementations cache, 
> because, well, mine don't. :-) My concern is, especially in streaming 
> implementations, that caching everything is antithetical to the very 
> nature of streaming where you typically don't even cache the document 
> you're working on now. On the other hand, I'm also increasingly 
> convinced that a streaming XInclude just isn't feasible when 
> XPointers are allowed, even basic element and bare name pointers. You 
> have to load and keep entire documents in memory. So maintaining a 
> cache would only be an issue if the cache exceeded available memory 
> while the individual documents didn't.

  Well that tend to prove that the people from FIXPtr had it wrong ;-)

> Still, even if this is to be implementation dependent (like XML 1.0) 
> that should be called out in the spec. XML 1.0 left a lot of things 
> unsaid it probably shouldn't have. There's no reason to repeat that 
> here.

  I do not disagree with the impact on streaming. But it is crucial also
for some classes of processing to be able to cache. Here is a bug report
  http://mail.gnome.org/archives/xml/2003-August/msg00052.html
XInclude being used for bank documentation processing, and an error 
in release 2.5.7 dropped XInclude caching, as a result processing the
document took 20 times more time. Not acceptable for that class of document.
  
  We should not prevent implementing a streaming subset. But we should
not prevent caching included resources. Seems the status quo does exactly
that. The only thing we may change is to indicate that the possibility
to cache or not is implementation dependant. Seems we both agree on that,
let's see what the Working Group think about this :-)

Daniel

-- 
Daniel Veillard      | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
daniel@veillard.com  | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ |

Received on Wednesday, 28 January 2004 05:36:08 UTC