Re: [xslt] xsltproc memory consumption w/ large DTD / docbook
- From: Daniel Veillard <veillard redhat com>
- To: xslt gnome org
- Subject: Re: [xslt] xsltproc memory consumption w/ large DTD / docbook
- Date: Sun, 2 Feb 2003 08:17:49 -0500
On Sun, Feb 02, 2003 at 11:50:38AM +0000, Sebastian Rahtz wrote:
>
> > I stand firm on this.
> >
> > > a simply well-formed document <x foo="bar"/>
> > > can have an XSLT process it under the assumption that "bar" is
> > > an entity (defined in the DTD subset)
> >
> > and need to map back to the system ID for that entity hence requiring
> > the entity declaration from the DTD. Please recheck the spec, I'm 95%
> > sure about this (but there is those 5% ...)
>
> yes, but the entity declaration can be in a DTD subset, and there need
> not be a full DTD. do we we agree
>
> <!DOCTYPE article [
> <!ENTITY foo "bar">
> ]>
> <article>&foo;</article>
>
> is reasonable XML?
it does not allow validation of the fragment, as a result not very
reasonable for a publishing use IMHO.
> > No, it will be read for every instance, even if XIncluded. As long
> > as the separate chunk references the DocBook DTd (and they do !)
>
> but those instance documents don't have to have DTD declarations.
> if they need entities, they can use the technique above, but
> I'd suggest that most people should move away from entities anyway.
not for character entity definitions in publishing space, there is
no replacement and charrefs are not meaninful to a human brain.
> If I was working in this scenario, I'd have one wrapper file
> for the whole site, XInlcuding all the individual files, which
> would simply be well-formed. I'd validate those using a schema.
We are still for docbook publishing working in a DTD based framework.
XInclude is fine, though, because it allows to DTD validate the fragments.
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/
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]