 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2012-03-02 04:25, Invisible a écrit :
> On 02/03/2012 05:54 AM, Darren New wrote:
>> On 2/29/2012 1:24, Invisible wrote:
>>> As far as I know, there is no way of using XHTML entities without also
>>> declaring that this is an XHTML document.
>>
>> Right. Because that would be meaningless.
>
> The point is, any XML document that contains text may potentially need
> non-ASCII characters. But only XML documents which are also XHTML can
> contain non-ASCII characters. How is that sensible?
Non-XHTML documents can and do contain non-ASCII characters. What you
meant to say is that you can't use their XHTML representations outside
an XHTML document. Case in point: a .DOCX file does not use é or
à but can most definitely contain the characters represented by
those entities.
--
/*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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 3/2/2012 1:25, Invisible wrote:
> The point is, any XML document that contains text may potentially need
> non-ASCII characters. But only XML documents which are also XHTML can
> contain non-ASCII characters. How is that sensible?
No. Only XML documents which are also XHTML documents can use the XHTML
standard for specifying ASCII-only names for non-ASCII characters.
You *can* put non-ASCII characters in an XML document. That's what the first
line is for, with the hard-to-remember code numbers, remember? Different
standards can have different entities. If I want an XML entity that
represents the symbol for the left eyeball, or an XML entity that represents
a internal link to the document management system of google, I can do that
-- just not in XHTML. Look at the triglyphs for C-on-punched-cards. Same
sort of thing. They're only applicable to C.
> Sure, having more than one DTD doesn't make a lot of sense. (Except that it
> would be nice to apply different DTDs to different namespaces. But that has
> little to do with entities.) The problem is that character entities are in
> the DTD, not defined in the XML spec for /everyone/ to use.
So type the characters directly. Nothing stops you from embedding a thron or
an omega in your document except that you don't want to learn how to type
one on the keyboard you have.
> OK. But it could make sense for different DTDs to apply to different
> subtrees, surely?
You still have to have one DTD that says where the trees are allowed to join
up. There's nothing that says that DTD isn't trivial to construct from two
other DTDs.
>>> I know that you /can/ stuff more than one namespace into an XML document.
>>> It's just that it doesn't /work/ when you try to use it.
>>
>> It ... works for me. You just have to (a) do it right and (b) have a
>> tool that supports it.
>
> Write at XHTML document which contains some MathML. Unless you use the magic
> XHTML+MathML DTD, it doesn't work at all. Clearly it /should/, but it doesn't.
Sure. You have to have the right DTD, because MathML expressions can't
appear inside URLs, nor can they appear as a child of a <meta> link in the
header, etc. You have to know the rules of where each can appear in the
other if you want to actually check it's right.
> In summary, XML doesn't provide the necessary tools to solve common problems
> such as mixing more than one markup together.
It does. You just don't like the solution. It's like you're saying "Haskell
doesn't provide the necessary tools to incorporate C syntax into its type
declarations." No, they're completely different type systems.
--
Darren New, San Diego CA, USA (PST)
People tell me I am the counter-example.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> The point is, any XML document that contains text may potentially need
>> non-ASCII characters. But only XML documents which are also XHTML can
>> contain non-ASCII characters. How is that sensible?
>
> No. Only XML documents which are also XHTML documents can use the XHTML
> standard for specifying ASCII-only names for non-ASCII characters.
Why would you want three different standard names for the same character?
> So type the characters directly. Nothing stops you from embedding a
> thron or an omega in your document except that you don't want to learn
> how to type one on the keyboard you have.
Well, for that matter, you can just type the Unicode code number
directly. (This at least works with all operating systems and text
editors, doesn't break every five minutes, etc.) It's just that
memorising large quantities of code numbers isn't exactly trivial.
>> OK. But it could make sense for different DTDs to apply to different
>> subtrees, surely?
>
> You still have to have one DTD that says where the trees are allowed to
> join up. There's nothing that says that DTD isn't trivial to construct
> from two other DTDs.
Well, if it were possible for one DTD to import several others, then it
could be pretty easy... As it is, constructing even one DTD is so
insanely hard that only the professionals can do it.
>> In summary, XML doesn't provide the necessary tools to solve common
>> problems
>> such as mixing more than one markup together.
>
> It does. You just don't like the solution.
What, a combinatorial explosion of DTDs for every possible combination
of XML applications that you might ever want to combine? No, that's just
silly.
> It's like you're saying
> "Haskell doesn't provide the necessary tools to incorporate C syntax
> into its type declarations." No, they're completely different type systems.
Not relevant, but: Actually Haskell does let you do this. There's a
standard preprocessor for exactly this task. People use it when binding
to external C or C++ libraries.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 3/3/2012 1:29, Orchid Win7 v1 wrote:
> Why would you want three different standard names for the same character?
What's the chinese word for "quotation mark"? For that matter, why would you
even want a "name" for a character, unless your text editor is too lame to
actually store the character? Leap-frog into the 21st century and start
using Windows Notepad to edit your text or something.
> Well, for that matter, you can just type the Unicode code number directly.
> (This at least works with all operating systems and text editors, doesn't
> break every five minutes, etc.) It's just that memorising large quantities
> of code numbers isn't exactly trivial.
Right. So you're complaining that XML is broken because your text editor
can't handle Unicode? Just type the unicode characters directly into the
text document, without using any code numbers.
> Well, if it were possible for one DTD to import several others, then it
> could be pretty easy... As it is, constructing even one DTD is so insanely
> hard that only the professionals can do it.
... says the man who programs in Haskell. ;-)
You don't really have to *import* DTDs. You can pretty much just concatenate
them, as long as there aren't conflicting definitions, and fix up only the
places where they actually interact. I mean, if you have some java-specific
XML (say, a build system), and you want to embed SVG into that (say, to
define the splash screen for the completed program), your build system is
going to have to understand how to interpret SVG.
> What, a combinatorial explosion of DTDs for every possible combination of
> XML applications that you might ever want to combine? No, that's just silly.
Why not? You get a combinatorial explosion of types in your computer
programs for every new program you write.
Generally, your XML processor has to understand the combination you're using
anyway, so it's not really obvious there's a problem here. It's not like
you're going to combine SEP and XHTML in one program and expect to not do
more work than frobbing around the DTD.
--
Darren New, San Diego CA, USA (PST)
People tell me I am the counter-example.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Why would you want three different standard names for the same character?
>
> What's the chinese word for "quotation mark"? For that matter, why would
> you even want a "name" for a character, unless your text editor is too
> lame to actually store the character? Leap-frog into the 21st century
> and start using Windows Notepad to edit your text or something.
It's not possible to type exotic characters. But it's trivial to type in
their names.
> Right. So you're complaining that XML is broken because your text editor
> can't handle Unicode? Just type the unicode characters directly into the
> text document, without using any code numbers.
...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
>> Well, if it were possible for one DTD to import several others, then it
>> could be pretty easy... As it is, constructing even one DTD is so
>> insanely hard that only the professionals can do it.
>
> ... says the man who programs in Haskell. ;-)
The problem is, the only real documentation on how to write DTDs is the
antiquated SGML reference documentation, which is hardly easy going.
From what I've seen from other written DTDs, it's just damned hard,
that's all.
>> What, a combinatorial explosion of DTDs for every possible combination of
>> XML applications that you might ever want to combine? No, that's just
>> silly.
>
> Why not? You get a combinatorial explosion of types in your computer
> programs for every new program you write.
Actually... no, you don't.
In any half-decent language, you can implement sorting and searching.
Once. In a language that's not so good, you have to reimplement this for
every individual datatype. And that's what the DTD situation feels like;
endlessly reimplementing the same language specs over and over again.
And these aren't exactly trivial languages... 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.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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. :-)
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?
> ...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.
> The problem is, the only real documentation on how to write DTDs is the
> antiquated SGML reference documentation, which is hardly easy going. From
> what I've seen from other written DTDs, it's just damned hard, that's all.
It's actually pretty straightforward. Google "dtd tutorial".
> 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 that a DTD is a type specification. It also originally
specified what closing tags could be left out by specifying what could be
nested inside what. (You don't have to close a paragraph in a book if the
next tag opens a new chapter, because chapters don't nest and paragraphs
can't contain chapters.)
So don't use a DTD. Use an XSL or whatever they call it these days.
--
Darren New, San Diego CA, USA (PST)
People tell me I am the counter-example.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|
