RE: [Bug 1222] Serialization - Extensibility

Thanks for the comment, Philip. As it happens, it's not ideal timing: we've
closed the books for comments during the "last call" period, and haven't yet
opened them for the "candidate recommendation" phase that hopefully will
come next. But the comment will be added to the list.

The purpose of the CR phase is to gather feedback to show that the specs are
implementable and usable, so there is still scope to consider changes in
details like this.

This decision was debated quite hotly. Actually two decisions: firstly to
add a rule to the serialization spec saying that C1 control characters in
HTML are an error that must be detected, and secondly, to say that extension
attributes in XSLT mustn't override this. The reasoning is that such
characters generally imply a character encoding error somewhere along the
line (typically Windows CP1252 encoding used in a file that wrongly declares
itself to be encoded in iso-8859-1), and the sooner such encoding errors are
detected, the easier it is to correct them.

Personally I'm a bit more inclined to pragmatism. I think the XQuery spec
has probably gone a bit too far by saying that vendor extensions can do
anything they like without limitation. (XQuery 4.16: "An option
declaration... may be used without limitation to modify the semantics of the
query".) But my own feeling is that this new rule in XSLT is too far in the
opposite direction. We've also recently spotted that it contradicts other
statements in the XSLT spec: section 2.9 Error Handling says "the effect of
serialization errors is implementation-defined", and section 20
Serialization says "If a processor serializes a final result tree, it
*should* do so as specified by [xsl:output]; however, it is not *required*
to do so." So we're going to have to take another look at it anyway.

Even if the XSLT spec does decide to stay with the very strict restrictions
on extensions, there's an escape clause that will remain: vendors are
allowed to provide their own serialization methods in addition to the
standard four. However, my view is that interoperability would suffer if we
pushed too many people down that route.

This, of course, is very much a personal response.

Michael Kay
Saxonica  

> -----Original Message-----
> From: public-qt-comments-request@w3.org 
> [mailto:public-qt-comments-request@w3.org] On Behalf Of 
> Philip Peterson
> Sent: 06 October 2005 18:46
> To: public-qt-comments@w3.org
> Subject: Re: [Bug 1222] Serialization - Extensibility
> 
> 
> Hello,
> 
> I've never posted to this type of forum before, and I hope I am doing
> so in the correct light, and at an appropriate time.
> 
> This comment is purely from a real world developer that hopes to move
> toward using XHTML as
> an output method but will be kept from getting to this point buy the
> following comment
> 
> Implementations may define additional serialization parameters....
> .....but they could not instruct the serializer to suppress the error
> that occurs when the
> html output method encounters illegal characters (see error SERE014).
> 
> 
> In the real world I will see the message.
> SERE0014: Illegal HTML character: decimal 149(as well as others)
> 
> <xsl:output method="html" indent="yes"/>
> if i change to
> <xsl:output method="xhtml" indent="yes"/>
> 
> it will fix my problem, however, It will cause other many problems
> with IE (the browser)
> and css that I cant resolve currently.
> 
> While I understand the goal (I think) of this spec, not allowing
> workarounds will eliminate a real world solution from a real world
> problem,  and is a bit draconian and not very pragmatic.
> 
> Thank you for all your hard work on this spec.
> 
> Sincerely,
> Philip Peterson
> 
> 
>

Received on Friday, 7 October 2005 08:39:59 UTC