Bug#733971: nginx-full: please provide XML entities
On Fri, Jan 03, 2014 at 01:55:55PM -0600, Michael Lustfield wrote: > That's perhaps a large way to say yes? I was just trying to ask a simpler > question. *If* an admin needs this file because they are using the xlst > module, will *this* file be exactly what 99.99% of people need with zero > modifications required? This file should cover all use cases that I can presently think of, because it implements the standard. Unless you really need to save a few bytes memory and storage OR need one of the other code points (some symbols can be encoded differently), I do not see why you would need to modify it. Kind regards, --Toni++ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#733971: nginx-full: please provide XML entities
> > > > http://nginx.org/en/docs/http/ngx_http_xslt_module.html#xml_entities > > > > > I'm not familiar with this module. What are the chances that admins will > > want to change this file? Will the defaults suffice for anyone/everyone > > (the 99.99%)? > > My estimate is that at least everyone who wants to proxy to Plone and > use XSLT, will need it. I arrived at this conclusion because I got > site-breaking errors without it (libxml2 parse errors in the middle of > the page and 404s for pages that definitely exist). > > IOW, if you are an XSLT user, I suspect that you will need such a file > unless your web pages are generated to contain no &somesymbol; type > entity references at all. I don't know what the default values that > nginx (libxml2, to be specific) knows about w/o having such a file, are. > Although I likely have no use for the bulk of the entries in that file, > simply implementing the entire standard was easier and safer than > picking a subset and shipping that. > That's perhaps a large way to say yes? I was just trying to ask a simpler question. *If* an admin needs this file because they are using the xlst module, will *this* file be exactly what 99.99% of people need with zero modifications required?
Bug#733971: nginx-full: please provide XML entities
Hi, On Fri, Jan 03, 2014 at 12:56:44PM -0600, Michael Lustfield wrote: > On Fri, Jan 3, 2014 at 9:03 AM, Toni Mueller wrote: > > Why? I am only aware of its usefulness in conjunction with the XSLT > > module. > Because nginx-full is the package for the "full" version of the nginx > binary. It will not have configuration files in it. This is what > nginx-common is for. It's for files that are common among the versions of > nginx binaries. hmmm... ok. > > http://nginx.org/en/docs/http/ngx_http_xslt_module.html#xml_entities > > > I'm not familiar with this module. What are the chances that admins will > want to change this file? Will the defaults suffice for anyone/everyone > (the 99.99%)? My estimate is that at least everyone who wants to proxy to Plone and use XSLT, will need it. I arrived at this conclusion because I got site-breaking errors without it (libxml2 parse errors in the middle of the page and 404s for pages that definitely exist). IOW, if you are an XSLT user, I suspect that you will need such a file unless your web pages are generated to contain no &somesymbol; type entity references at all. I don't know what the default values that nginx (libxml2, to be specific) knows about w/o having such a file, are. Although I likely have no use for the bulk of the entries in that file, simply implementing the entire standard was easier and safer than picking a subset and shipping that. Kind regards, --Toni++ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#733971: nginx-full: please provide XML entities
On Fri, Jan 3, 2014 at 9:03 AM, Toni Mueller wrote: > > On Fri, Jan 03, 2014 at 08:42:17AM -0600, Michael Lustfield wrote: > > It definitely won't be part of nginx-full. It will either be part of > > Why? I am only aware of its usefulness in conjunction with the XSLT > module. > Because nginx-full is the package for the "full" version of the nginx binary. It will not have configuration files in it. This is what nginx-common is for. It's for files that are common among the versions of nginx binaries. > > > nginx-doc or nginx-common. Where does this file need to physically sit in > > order for Nginx to behave correctly and are any config options needed? > > You can place it wherever you want, but you need to reference it from > the configuration, like described here: > > http://nginx.org/en/docs/http/ngx_http_xslt_module.html#xml_entities > > I'm not familiar with this module. What are the chances that admins will want to change this file? Will the defaults suffice for anyone/everyone (the 99.99%)?
Bug#733971: nginx-full: please provide XML entities
On Fri, Jan 03, 2014 at 08:42:17AM -0600, Michael Lustfield wrote: > It definitely won't be part of nginx-full. It will either be part of Why? I am only aware of its usefulness in conjunction with the XSLT module. > nginx-doc or nginx-common. Where does this file need to physically sit in > order for Nginx to behave correctly and are any config options needed? You can place it wherever you want, but you need to reference it from the configuration, like described here: http://nginx.org/en/docs/http/ngx_http_xslt_module.html#xml_entities Kind regards, --Toni++ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#733971: nginx-full: please provide XML entities
> On Fri, Jan 03, 2014 at 11:10:34AM +0200, Christos Trochalakis wrote: > > On Thu, Jan 02, 2014 at 07:38:51PM +0100, Toni Mueller wrote: > > >I recently discovered that the XSLT module does not work very well > > >because of a missing list of entities. So I went to the W3C and then > > >generated one, which works OK at my side. It would be nice if you could > > >include the file with the next version(s) of the package. > > Yes, we could ship a sample dtd with nginx-doc package. > > I rather suggest shipping it with nginx-full, as one needs the file in > case a backend does emit the entity references, instead of the binary > code points. Eg. I need it to process output from Plone. > It definitely won't be part of nginx-full. It will either be part of nginx-doc or nginx-common. Where does this file need to physically sit in order for Nginx to behave correctly and are any config options needed?
Bug#733971: nginx-full: please provide XML entities
Hi Christos, On Fri, Jan 03, 2014 at 11:10:34AM +0200, Christos Trochalakis wrote: > On Thu, Jan 02, 2014 at 07:38:51PM +0100, Toni Mueller wrote: > >I recently discovered that the XSLT module does not work very well > >because of a missing list of entities. So I went to the W3C and then > >generated one, which works OK at my side. It would be nice if you could > >include the file with the next version(s) of the package. > Yes, we could ship a sample dtd with nginx-doc package. I rather suggest shipping it with nginx-full, as one needs the file in case a backend does emit the entity references, instead of the binary code points. Eg. I need it to process output from Plone. > What did you use as a source for those entities? Could you provide a > link? Sure. I converted this file: http://www.w3.org/TR/html5/entities.json Kind regards, --Toni++ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#733971: nginx-full: please provide XML entities
Hello Toni, On Thu, Jan 02, 2014 at 07:38:51PM +0100, Toni Mueller wrote: Package: nginx-full Version: 1.4.1-3~bpo70+1 Severity: wishlist Dear Maintainer, I recently discovered that the XSLT module does not work very well because of a missing list of entities. So I went to the W3C and then generated one, which works OK at my side. It would be nice if you could include the file with the next version(s) of the package. Yes, we could ship a sample dtd with nginx-doc package. What did you use as a source for those entities? Could you provide a link? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
