Re[5]: WG: [xslt] decimal char problem - possible Solution

[Marco Stipek <stipek triplex de>]

Hi Daniel,

Thursday, September 13, 2001, 6:39:01 PM, you wrote:

DV>   There is multiple ways to attack the problem:
DV>     - use the XML serializer i.e. not use method="html",
DV>       I think it opens the door to a number of more subtle violations.
DV>       section 16.2 of the XSLT REC should be sufficient to convince
DV>       people that it is a dead end.
I totaly agree with you, this is I think the worst solution.

DV>     - use the HTML serializer without an encoding declaration
DV>       this mean fixing the UTF8ToHtml() output to be compatible with
DV>       Netscape 4, it's bad but just reflect that HTML implementations
DV>       are bad.
Obviously not only NS ha problems (s. other posting complaining about
opera), not speeking from Macintosh Browsers. I think (as mentioned in
another post) libxml should support the features available throughout
the standards. So I belive, that should be possible to choose the
output encoding of character entities in a "configurable" way.
Default behaviour could be the old one, than nothing could break by
this change. Exceptionally I belive that we don't introduce bad
behaviour error handling we only add a feature allowed by standards.
I think you don't reflect bad HTML implementations only incomplete.
And exceptionally in this case a fix will conform to the standards.
That are the reasons we support a change at this point.

DV>     - use the HTML serializer without an encoding declaration
DV>       by registering your own "html encoder" this is a relatively
DV>       simple and clean way to implement you own rules even if libxml
DV>       is not changed the way you like
Yes but as you can see by the postings there is a great demand for
having a browser compatible behaviour as far as it is in conformance
with standards. We could implement it but I think a more general
solutions should be found at this point.

DV>     - use the HTML serializer and forcing ISO Latin 1 encoding, in
DV>       that case the fallback to convert "unsupported chars" to 
DV>       a charref could be switched to decimal.
But in this case you have to leaf the standards and support the
miss behaviour you mentioned yourself regarding œ etc.
I think this is a worse method, because then you begin to implement
browser specific behaviour into the libs. This will be a never ending
story (as we made all our painful experiences.

DV>   As you can see just in 10 mn I can come with very different solutions
DV> to solve this, including one which would work right now without changing
DV> libxml2 ...
We didn't never blame your skills, we hope you understand us right!

DV>   I'm tempted to change the default behaviour as you initially suggested
DV> but it was not clear at all it is the right way, there was a lot of 
DV> other constraints and possibilities not described.
Are you still tempted to do it? We'll wait on your final decision.


best regards,
 Marco
-----------------------------------------------------------------------
Marco Stipek

triplex - agentur fuer neue medien GmbH
Herzog-Heinrich-Strasse 11-13
80336 Muenchen


Tel: +49 89 209138-23
Fax: +49 89 209138-10
mailto:stipek@triplex.de
http://www.triplex.de
-----------------------------------------------------------------------