On 04/03/2012 00:08, Darren New wrote:
> On 3/3/2012 14:04, Orchid Win7 v1 wrote:
>> It's not possible to type exotic characters.
>
> Sure it is. I just turned on chinese for my wife. Use alt-shift to
> toggle between languages. :-)

That doesn't make the characters available on your keyboard though. It's 
not like you can just press a button and have a different set of 
characters printed on your physical keyboard.

> The problem is that your *editor* doesn't make it simple to type exotic
> characters, yes? Why do you complain that your XML processor doesn't
> understand exotic characters when its your editor that makes them
> difficult to type?

It's not the editor that makes them hard to type. It's the fact that 
computer keyboards only have a few hundred keys, not several billion 
keys. (Heck, even then it would be pretty difficult to actually /find/ 
the one you want...)

In most situations, that just means that you flat-out /can't/ use 
unusual characters. HTML, and now XHTML, are fairly unusual in that they 
let you type in the character's name if you can't easily type the 
character itself. Unfortunately, rather than make this useful feature 
available to all XML applications, they arbitrarily chose to make it 
available to only one.

>> ...aaaand then watch it break into a thousand pieces because raw text
>> files
>> have no way of specifying what actual character encoding is being
>> used. :-P
>
> That's why the first line of your XML document includes the character
> set in which the rest of the document is written. *right there* is the
> reason you have to put <?xml ...> at the start, along with the funky
> code number for your character set.

That tells an XML processor what the character encoding is. It does not 
tell your text editor what the encoding is.

>> It would be frighteningly easy to come up with
>> an XHTML+MathML DTD where the XHTML part doesn't actually match the
>> stand-alone XHTML DTD, for example.
>
> Sure. And it would be frighteningly easy to come up with a generic
> sorting algorithm that works incorrectly on certain types. Don't do that.

The point is, to make a DTD for a combination of trees, you have to 
/copy/ the DTDs for each subtree - and hope that you don't do it wrong. 
Talk above violating the DRY printiple...

Post a reply to this message

On 3/4/2012 9:07, Orchid Win7 v1 wrote:
> That doesn't make the characters available on your keyboard though. It's not
> like you can just press a button and have a different set of characters
> printed on your physical keyboard.

Actually, you can, yes. http://www.lcd-keys.com/english/history.htm

:-)

> It's not the editor that makes them hard to type. It's the fact that
> computer keyboards only have a few hundred keys, not several billion keys.

And yet, oddly enough, billions of chinese people seem to get along OK.

It's still the case that you're addressing the wrong technology. The file 
itself has no trouble storing the characters, yet you want the file storage 
technology to compensate for your computer's inability to put the characters 
into the file conveniently.

Fix your input mechanism, and store the characters. Don't fix every program 
that reads characters to deal with names. Fix your *editor* to deal with 
names. Make it so when you type &acut; into your editor, it replaces it with 
the right unicode character. Problem solved.

> type in the character's name if you can't easily type the character itself.

Why doesn't your editor do this?

> Unfortunately, rather than make this useful feature available to all XML
> applications, they arbitrarily chose to make it available to only one.

Because different XML applications need different character entities.

> That tells an XML processor what the character encoding is. It does not tell
> your text editor what the encoding is.

So always use UTF-8 or something. Or write your editor to recognize an XML 
header and parse it.

> The point is, to make a DTD for a combination of trees, you have to /copy/
> the DTDs for each subtree - and hope that you don't do it wrong. Talk above
> violating the DRY printiple...

But to *use* a DTD for a combination of trees, you have to implement an 
entire program to do so. So the actual concatenation of two files is rather 
simple, comparatively speaking.

-- 
Darren New, San Diego CA, USA (PST)
   People tell me I am the counter-example.

Post a reply to this message

Am 04.03.2012 18:07, schrieb Orchid Win7 v1:
> On 04/03/2012 00:08, Darren New wrote:
>> On 3/3/2012 14:04, Orchid Win7 v1 wrote:
>>> It's not possible to type exotic characters.
>>
>> Sure it is. I just turned on chinese for my wife. Use alt-shift to
>> toggle between languages. :-)
>
> That doesn't make the characters available on your keyboard though. It's
> not like you can just press a button and have a different set of
> characters printed on your physical keyboard.

That /may/ depend on your keyboard...

http://www.artlebedev.com/everything/optimus/maximus/

> In most situations, that just means that you flat-out /can't/ use
> unusual characters. HTML, and now XHTML, are fairly unusual in that they
> let you type in the character's name if you can't easily type the
> character itself. Unfortunately, rather than make this useful feature
> available to all XML applications, they arbitrarily chose to make it
> available to only one.

Did anyone already mention that they did /not/ "arbitrarily" choose "to 
make it available to only one", but rather /deliberately/ chose to make 
it availabe to /this/ one (despite the general decision to keep the XML 
set of character entities simple), because "we'll never get people to 
convert from HTML if they can't do this in XHTML"?

>
>>> ...aaaand then watch it break into a thousand pieces because raw text
>>> files
>>> have no way of specifying what actual character encoding is being
>>> used. :-P
>>
>> That's why the first line of your XML document includes the character
>> set in which the rest of the document is written. *right there* is the
>> reason you have to put <?xml ...> at the start, along with the funky
>> code number for your character set.
>
> That tells an XML processor what the character encoding is. It does not
> tell your text editor what the encoding is.

How about rephrasing this: "It does not /necessarily/ tell your text 
editor what the encoding is."

What part of "get a decent text editor" didn't you understand? :-P

> The point is, to make a DTD for a combination of trees, you have to
> /copy/ the DTDs for each subtree - and hope that you don't do it wrong.
> Talk above violating the DRY printiple...

... which is why there is XML Schema. And XML namespaces.

Post a reply to this message

>> That tells an XML processor what the character encoding is. It does not
>> tell your text editor what the encoding is.
>
> How about rephrasing this: "It does not /necessarily/ tell your text
> editor what the encoding is."
>
> What part of "get a decent text editor" didn't you understand? :-P

Can you name one single text editor which can actually change character 
encoding based on a mere XML encoding specification?

Post a reply to this message

Le 2012-03-05 03:54, Invisible a écrit :
>>> That tells an XML processor what the character encoding is. It does not
>>> tell your text editor what the encoding is.
>>
>> How about rephrasing this: "It does not /necessarily/ tell your text
>> editor what the encoding is."
>>
>> What part of "get a decent text editor" didn't you understand? :-P
>
> Can you name one single text editor which can actually change character
> encoding based on a mere XML encoding specification?

I would bet emacs does it, since it does everything, including sorting 
laundry and fixing tires.

But seriously, though, http://www.lmgtfy.com/?q=xml+editors
-- 
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/*    flabreque    */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/*        @        */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/*   gmail.com     */}camera{orthographic location<6,1.25,-6>look_at a }

Post a reply to this message

>>> What part of "get a decent text editor" didn't you understand? :-P
>>
>> Can you name one single text editor which can actually change character
>> encoding based on a mere XML encoding specification?
>
> I would bet emacs does it, since it does everything, including sorting
> laundry and fixing tires.

Yeah. But then I'd have to use Emacs...

> But seriously, though, http://www.lmgtfy.com/?q=xml+editors

Right. Because my text editor only needs to edit XML. Oh, wait...

In all seriousness though. I could probably just configure my editor to 
always use UTF-8. That still doesn't solve the problem of typing obscure 
characters in the first place. And it still doesn't change the fact that 
as soon as I open the file in any other program, it's going to break 
because that other program doesn't know what the hell character encoding 
to use.

Post a reply to this message

Am 05.03.2012 09:54, schrieb Invisible:
>>> That tells an XML processor what the character encoding is. It does not
>>> tell your text editor what the encoding is.
>>
>> How about rephrasing this: "It does not /necessarily/ tell your text
>> editor what the encoding is."
>>
>> What part of "get a decent text editor" didn't you understand? :-P
>
> Can you name one single text editor which can actually change character
> encoding based on a mere XML encoding specification?

The integrated text editors of both MS Visual Studio 2010 and 
BeyondCompare 3.0 definitely do it (and yes, I'm talking about plain 
"ASCII" text editors, not dedicated XML editor components).

As for stand-alone text editors, I've not used any for years, but I 
wouldn't be surprised if current versions of e.g. UltraEdit would be 
doing this as well (it does have some "auto-detect UTF-8 encoding" 
option after all, though I can't find any details about the magic used 
in there).

Post a reply to this message

Am 05.03.2012 19:19, schrieb Orchid Win7 v1:
>>>> What part of "get a decent text editor" didn't you understand? :-P

> In all seriousness though. I could probably just configure my editor to
> always use UTF-8. That still doesn't solve the problem of typing obscure
> characters in the first place.

Did you know that good text editors allow you to define your own fancy 
keystroke combinations? So you can place your favorite special 
characters on some easily memorizable combo of Alt-Shift-Explode or 
whatever suits your needs.

> And it still doesn't change the fact that
> as soon as I open the file in any other program, it's going to break
> because that other program doesn't know what the hell character encoding
> to use.

That's plain stupid nonsense. A non-UTF-8-aware text editor (or any 
other piece of software capable of processing extended-ASCII text files) 
confronted with a UTF-8 text file will display apparently random stuff 
in place of any non-ASCII characters, but that random stuff saves fine, 
and parses back as later UTF-8 without problem. Just make sure you don't 
insert non-ASCII characters in the troublesome editor, and don't insert 
anything into that random stuff.

This property is one of the fun things about UTF-8: Anything that can 
handle at least /one/ extended-ASCII codepage can also handle UTF-8 
transparently without even knowing.

(You /will/ get into trouble though if your <?xml ...?> declaration 
doesn't match the actual character encoding of the file, but I guess 
that should be obvious.)

Post a reply to this message

On Mon, 05 Mar 2012 20:10:56 +0100, clipka wrote:

> Alt-Shift-Explode

I need a keyboard that has that as an option on it. :)

Jim

Post a reply to this message

On 3/4/2012 18:05, clipka wrote:
> ... which is why there is XML Schema. And XML namespaces.

Actually, I'd be happy if once, once in my career, someone would provide me 
"an XML feed" that could actually be parsed by an XML library without first 
having to do a bunch of string crap to it to make it right.

-- 
Darren New, San Diego CA, USA (PST)
   People tell me I am the counter-example.

Post a reply to this message