>> Ah. So in fact, the W3C specification is broken, since /clearly/ a
>> system should not be specified to suddenly produce completely incorrect
>> output if an optional feature is not implemented.
>
> That's why they warn about this possible difference, so that the user
> can decide whether to (a) make sure that the XSLT file is only used with
> an XSLT processor that supports the feature, or (b) make sure that the
> output is not *completely* incorrect if the feature is unavailable.
>
> That's not broken spec, that's just perfectly normal optional features.

It's a broken spec, in that it provides no way to design a transform so 
that if DEO is not implemented, the output still looks sane. There isn't 
even a way to say "sorry, the required feature is not available". 
Instead, it just prints random gibberish without telling you or giving 
you any chance to correct it.

>> Meanwhile, it looks like my only options are either to start memorising
>> Unicode code points by ID, or to save my XSL file as UTF-8 and watch the
>> encoding get screwed up every time I touch the file...
>
> Ah, so your /real/ problem is a crappy text editor.

The /real/ problem is that there is no way of knowing what encoding a 
given text file has. So it's not safe to use non-ASCII characters in a 
text file. Which is why character entities were invented in the first 
place...

>> (Let's not even get into the question of why the standard character
>> names /only/ work in HTML, and not all SGML file types...)
>
> Because they're a HTML-specific invention?

Um, why?

It's not like only HTML could possibly need non-ASCII characters.

Post a reply to this message