 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 23.02.2012 22:14, schrieb Orchid Win7 v1:
> On 23/02/2012 17:35, Warp wrote:
>> Support for UTF-16 is still relatively poor (although getting better).
>> Most modern browsers should handle it ok, though, but it requires for the
>> server to send the proper http header to tell the browser the encoding,
>> and configuring the server to do this might not be trivial. (A html file
>> encoded in UTF-16 will look like garbage.)
>
> Isn't that what the HTML encoding tag is for? Or the XML encoding
> declaration?
You can't read those until you know at least some basics about the
encoding :-P
That's /one/ reason why XML requires UTF-16 files to start with a byte
order mark: If the file starts with "FE FF" or "FF FE", it's either
UTF-16, malformed XML (not starting with optional whitespace followed by
"<?"), or indeed garbish, so UTF-16 is a safe bet in that case.
Otherwise rely on the file format being backward compatible with ASCII,
and treat it as UTF-8 (which is ASCII-compatible as well) until an
encoding declaration tells you otherwise.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2/23/2012 11:06, Warp wrote:
> It's verbose, but it has one advantage over most other formats: It's
> standardized and pretty well supported.
It also has an advantage in that it's a *markup language*. That's what it's
for. Just as it sucks for passing around arrays of floats or passing pov-ray
data objects between clusters of renderers or encoding routing table
updates, it does pretty darn good at things like writing help pages, user
manuals, and so on.
Bitching that XML is poorly suited for something it was never designed to do
is just pointless.
It's only verbose if you're not using it to pass around human-readable prose.
--
Darren New, San Diego CA, USA (PST)
People tell me I am the counter-example.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Isn't that what the HTML encoding tag is for? Or the XML encoding
>> declaration?
>
> You can't read those until you know at least some basics about the
> encoding :-P
Yeah. Isn't that fun? :-D
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 23/02/2012 07:06 PM, Warp wrote:
> It's verbose, but it has one advantage over most other formats: It's
> standardized and pretty well supported.
Well, it was that or JSON.
In my case, XML has XSLT. JSON does not possess anything comparable.
What that means is that just by outputting my data as XML, I can easily
transform it into something usable later. And I don't have to implement
the transformation engine myself - just the actual transformation rules.
(Which is still pretty non-trivial, mind you.)
(The other possibility is the unspeakably awful YAML...)
Some people /do/ use XML in some pretty inappropriate ways. (E.g., "if
we store all our data as XML, we won't have to ask the DB admin to
change the DB schema for us, and we can just run all the queries on the
client-side instead".) Just because people do stupid things with XML,
does not mean that XML is stupid.
That said, it /does/ seem overly complicated for the simple problem it's
supposed to solve...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymous org> wrote:
> That's /one/ reason why XML requires UTF-16 files to start with a byte
> order mark: If the file starts with "FE FF" or "FF FE", it's either
> UTF-16, malformed XML (not starting with optional whitespace followed by
> "<?"), or indeed garbish, so UTF-16 is a safe bet in that case.
> Otherwise rely on the file format being backward compatible with ASCII,
> and treat it as UTF-8 (which is ASCII-compatible as well) until an
> encoding declaration tells you otherwise.
OTOH, it would be quite trivial to guess that a HTML/XML file is
UTF-16-encoded: If each other byte is 0 and each other form valid
HTML/XML (at least up to the header section that specifies the encoding),
then it's a safe bet that it's UTF16-encoded.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New escreveu:
> On 2/23/2012 11:06, Warp wrote:
>> It's verbose, but it has one advantage over most other formats: It's
>> standardized and pretty well supported.
>
> It also has an advantage in that it's a *markup language*. That's what
> it's for. Just as it sucks for passing around arrays of floats or
> passing pov-ray data objects between clusters of renderers or encoding
> routing table updates, it does pretty darn good at things like writing
> help pages, user manuals, and so on.
>
> Bitching that XML is poorly suited for something it was never designed
> to do is just pointless.
Precisely so, like implementing validators or transformers for xml docs.
How recursive and verbose you can get? "Hey, Darren, have you already
wrote that xml document to validate the xml document validator that
validates our client xml document?"
I can't actually believe a typeful haskell supporter (I'm looking at
Orchid) is here advocating an xml document rather than writing a typeful
haskell program to validate data marshalling.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2/24/2012 1:10, Invisible wrote:
> That said, it /does/ seem overly complicated for the simple problem it's
> supposed to solve...
What simple problem do you think it was supposed to solve?
--
Darren New, San Diego CA, USA (PST)
People tell me I am the counter-example.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 25/02/2012 06:04, Darren New wrote:
> On 2/24/2012 1:10, Invisible wrote:
>> That said, it /does/ seem overly complicated for the simple problem it's
>> supposed to solve...
>
> What simple problem do you think it was supposed to solve?
The problem of marking up textual data.
A lot of people seem to think that if you just write some stuff in angle
brackets, that's XML. But it' actually far more complicated than that.
(As an aside, those aren't angle brackets. They're inequality signs. :-P
But I digress...)
For example, to say "this XML file actually contains XHTML", you're
supposed to add something like 5 separate headers, each about 25 million
miles long, to the top of the file. Why? Would one header not be sufficient?
Then there's all that stupidity with character entities. It should be
possible to include character entities in /all/ XML documents, not just
XHTML. But to this day, I have never discovered a way of doing this.
One of the nice ideas of XML is that you can use namespaces to include
one sort of XML document inside enought - e.g., you could put an SVG
file inside an XHTML file. But nooo, apparently you need a specialised
DTD to do that. In fact, you need one DTD for XHTML + SVG, another,
different DTD for XHTML + MathML, a third, different DTD for XHTML +
MathML + SVG, and... ARE YOU PEOPLE INSANE?!
In short, most people just end up sticking stuff in angle brackets and
calling that XML. /Actual/ XML is far too complicated.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2/25/2012 2:37, Orchid Win7 v1 wrote:
> For example, to say "this XML file actually contains XHTML", you're supposed
> to add something like 5 separate headers, each about 25 million miles long,
> to the top of the file. Why? Would one header not be sufficient?
Really? What do you have to add? I suspect you exaggerate a bit.
> Then there's all that stupidity with character entities. It should be
> possible to include character entities in /all/ XML documents, not just
> XHTML. But to this day, I have never discovered a way of doing this.
You have to declare the entities. Otherwise, you run across &frump; and
don't know what it means. That's what DTDs are for.
> One of the nice ideas of XML is that you can use namespaces to include one
> sort of XML document inside enought - e.g., you could put an SVG file inside
> an XHTML file. But nooo, apparently you need a specialised DTD to do that.
You can. Of course, your various processors have to know what the various
namespaces *mean*, so you have to declare them and you have to have a
processor that understands them (which is where the DTDs come in).
--
Darren New, San Diego CA, USA (PST)
People tell me I am the counter-example.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 26/02/2012 12:35 AM, Darren New wrote:
> On 2/25/2012 2:37, Orchid Win7 v1 wrote:
>> For example, to say "this XML file actually contains XHTML", you're
>> supposed
>> to add something like 5 separate headers, each about 25 million miles
>> long,
>> to the top of the file. Why? Would one header not be sufficient?
>
> Really? What do you have to add? I suspect you exaggerate a bit.
First, you must say
<?xml version="1.0" encoding="ISO-8859-1" ?>
Which is fair enough, although the 5-digit ISO code number isn't exactly
easy to remember. Then you have to say
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
Yeah, I'm really going to remember that without looking it up. :-P No,
you can't just say "this is XHTML". You really do have to write all that
crap. And after /that/, you still have to say
<html xmlns="http://www.w3.org/1999/xhtml">
Um, didn't I just declare this as XHTML already? At least this URL is a
bit shorter, I guess...
In short, that's a /hell/ of a lot of typing, before I've even written
my document. It's also a lot of typing that I have to go look up on
three different websites every single damned time I want to write XHTML.
>> Then there's all that stupidity with character entities. It should be
>> possible to include character entities in /all/ XML documents, not just
>> XHTML. But to this day, I have never discovered a way of doing this.
>
> You have to declare the entities. Otherwise, you run across &frump; and
> don't know what it means. That's what DTDs are for.
So why isn't there a DTD somewhere that contains all the entities that
everybody uses, which I can just link to? More to the point, since
everybody uses the same set of entities, why aren't they built in?
>> One of the nice ideas of XML is that you can use namespaces to include
>> one
>> sort of XML document inside enought - e.g., you could put an SVG file
>> inside
>> an XHTML file. But nooo, apparently you need a specialised DTD to do
>> that.
>
> You can. Of course, your various processors have to know what the
> various namespaces *mean*, so you have to declare them and you have to
> have a processor that understands them (which is where the DTDs come in).
You would /think/ you could just say "hey, this stuff here is in the
XHTML namespace, this stuff here is in the SVG namespace", and that
would work. But it doesn't. You need to use a DTD specially written for
the exact combination of XHTML+SVG. To me, this indicates that the
system is fundamentally broken. It should not be necessary to write a
separate DTD for every possible combination of XML documents imaginable.
You should just be able to refer to the DTD for XHTML and the DTD for
SVG and have it work.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
