On 21/02/2012 17:14, Warp wrote:
> Invisible<voi### [at] devnull>  wrote:
>> Sure, that works. But now suppose I have /more than one/ XSL file. In
>> order to select which one I want applied, I have to actually edit the
>> XML file.
>
>    What do you expect? For the XML file to read your mind?

No, I wanted to put that information into a separate file, that's all. 
It's not a complex idea.

Post a reply to this message

Orchid Win7 v1 <voi### [at] devnull> wrote:
> On 21/02/2012 17:14, Warp wrote:
> > Invisible<voi### [at] devnull>  wrote:
> >> Sure, that works. But now suppose I have /more than one/ XSL file. In
> >> order to select which one I want applied, I have to actually edit the
> >> XML file.
> >
> >    What do you expect? For the XML file to read your mind?

> No, I wanted to put that information into a separate file, that's all. 
> It's not a complex idea.

  Create an xml file that includes (using XInclude) the other XML file
you want as well as the xsl file?

-- 
                                                          - Warp

Post a reply to this message

Am 21.02.2012 11:09, schrieb Invisible:

>> The spec concludes that "Since disabling output escaping may not work
>> with all XSLT processors and can result in XML that is not well-formed,
>> it should be used only when there is no alternative."
>
> 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.

> 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.

> (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?

Post a reply to this message

On 21/02/2012 08:40 PM, Warp wrote:
> Orchid Win7 v1<voi### [at] devnull>  wrote:
>> On 21/02/2012 17:14, Warp wrote:
>>> Invisible<voi### [at] devnull>   wrote:
>>>> Sure, that works. But now suppose I have /more than one/ XSL file. In
>>>> order to select which one I want applied, I have to actually edit the
>>>> XML file.
>>>
>>>     What do you expect? For the XML file to read your mind?
>
>> No, I wanted to put that information into a separate file, that's all.
>> It's not a complex idea.
>
>    Create an xml file that includes (using XInclude) the other XML file
> you want as well as the xsl file?

That's a great idea. Except that apparently no browser supports XInclude 
yet. As I pointed out in my original post.

Post a reply to this message

>> 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

Am 22.02.2012 10:07, schrieb Invisible:

>>> 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...

Use an editor that places a BOM at the start of UFT-8 files and bob's 
your uncle.

Post a reply to this message

>>> 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...
>
> Use an editor that places a BOM at the start of UFT-8 files and bob's
> your uncle.

In other words, "there is this informal undocumented /convention/ that 
if a file starts with a BOM [even though UTF-8 does not require such a 
mark, since there /is/ no byte order], then it is presumed to contain 
UTF-8".

I wonder how widely implemented this undocumented feature is?

Post a reply to this message

Am 22.02.2012 22:28, schrieb Orchid Win7 v1:

>> Use an editor that places a BOM at the start of UFT-8 files and bob's
>> your uncle.
>
> In other words, "there is this informal undocumented /convention/ that
> if a file starts with a BOM [even though UTF-8 does not require such a
> mark, since there /is/ no byte order], then it is presumed to contain
> UTF-8".
>
> I wonder how widely implemented this undocumented feature is?

Most likely more widespread than you think.

As an alternative, forget UTF-8 and go for UTF-16.

Post a reply to this message

>> I wonder how widely implemented this undocumented feature is?
>
> Most likely more widespread than you think.

I got the distinct impression that this is a Windows-specific 
convention. (Doesn't Linux do something strange with using environment 
variables to define the "system locale"?)

> As an alternative, forget UTF-8 and go for UTF-16.

Or that, I suppose.

This still leaves me with the problem of how to generate unusual 
characters in the first place. Typing → is pretty simple. Figuring 
out how to actually generate the arrow character is not.

Post a reply to this message

Le 23/02/2012 10:11, Invisible a écrit :
> This still leaves me with the problem of how to generate unusual
> characters in the first place. Typing → is pretty simple. Figuring
> out how to actually generate the arrow character is not.

You just need the right documentation.
Either you search it each time on the web (like "utf-8 chartable"... )

or you call it correctly, and ask for unicode (utf-8 is one
presentation, unicode is what you really want), and get to print the
parts that you need often.

See http://unicode.org/charts/

And soon you will discover that there is no single font to display all
possible unicode glyphs.

You also need a unicode-compatible editor...

Post a reply to this message