Re: Re[5]: WG: [xslt] decimal char problem - possible Solution
- From: Daniel Veillard <veillard redhat com>
- To: xslt gnome org
- Subject: Re: Re[5]: WG: [xslt] decimal char problem - possible Solution
- Date: Thu, 13 Sep 2001 14:23:49 -0400
On Thu, Sep 13, 2001 at 02:11:01PM -0400, Ignacio Vazquez-Abrams wrote:
> > 1/ Shall we fix htmlEncodeEntities() to only generate entities
> > accepted by all browsers, what is the list one should deprecate ?
> > The list in html40EntitiesTable[] is fairly long.
>
> -1. This sounds wrong.
Be lax in what you accept and stric in what you generate has been
a design rule at the IETF for years. this is in that perspective.
> > 2/ Or should we try to provide an alternative encoding name "htmlcompat"
> > generating ISOLatin1 and the entity subset ?
>
> -1. Major breakage, no?
no because nobody would use
<xsl:output method="html" encoding="htmlcompat"/>
whithout knowing what they are doing. No breakage from my point of view.
> > 3/ Or should people just use encoding="ISO-8859-1" and make sure charrefs
> > in this case are encoded decimally ?
>
> -1. See my response to point 1.
which wasn't an argumented response and so is this one.
> > 4/ Any other option ? like sticking to what Xalan or Saxon does.
>
> How about supplementing <xsl:output/> with another attribute
> (enttype="[hex|dec|char]") or another tag (<exslt:output/>)?
in essence making the input not compliant to either XSLT or EXSLT,
*that* is seriously wrong IMHO.
Daniel
--
Daniel Veillard | Red Hat Network http://redhat.com/products/network/
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]