 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
The trouble with the whole xml thing is that it's just another
enterprisey BS to grind CPUs idle times. You need an xml document, an
xml document describing the structure of the previous document, yet
another xml document to describe how to style the original document
itens, perhaps a xml document describing how to transform your xml
document into another xml document. It's an insanely verbose and
homogeneous pile of human and machine barely readable crap.
People resented it and thus insist on saner formats, such as CSS, JSON
and real programming languages rather than a shitload of xml abstraction
layers, tools and java frameworks.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 23.02.2012 18:35, schrieb Warp:
> clipka<ano### [at] anonymous org> wrote:
>> As an alternative, forget UTF-8 and go for UTF-16.
>
> UTF-16 is more compact if the text consists mostly of non-ascii
> characters, especially if it contains eg. kanji symbols, hiragana, etc.
> (The vast majority of Japanese kanji can be expressed with 2 bytes using
> UTF-16 but require 3 bytes with UTF-8.)
>
> However, if the text consists mostly of ascii characters, such as
> English usually does, then UTF-8 is more compact than UTF-16 (which will
> basically double the size of the file).
I guess a factor 2 in text stream size is not a serious problem with
today's internet bandwidths.
> 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.)
It didn't sound like Andy would want to retrieve the XML file from a web
server, but rather directly from the local file system. Otherwise he
could simply go for server-side XSLT processing.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 23.02.2012 19:04, schrieb nemesis:
> The trouble with the whole xml thing is that it's just another
> enterprisey BS to grind CPUs idle times. You need an xml document, an
> xml document describing the structure of the previous document, yet
> another xml document to describe how to style the original document
> itens, perhaps a xml document describing how to transform your xml
> document into another xml document. It's an insanely verbose and
> homogeneous pile of human and machine barely readable crap.
>
> People resented it and thus insist on saner formats, such as CSS, JSON
> and real programming languages rather than a shitload of xml abstraction
> layers, tools and java frameworks.
Businesses do use it quite a lot for data exchange.
But yes, XML as a mere replacement for HTML is a rather silly thing
(except in its incarnation as XHTML); its legitimate ecologic niche on
the web is on the server side (if anywhere), and its native habitat is
actually totally somewhere else.
In some sense, XML is today's CSV: A generic file or data stream format
a human /can/ create, read and/or modify with an ASCII text editor, but
that still follows certain clear-cut rules that it can also be evaluated
by software; and actually just a meta-format, in the sense that the
content of the individual data fields needs to be agreed upon separately.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis <nam### [at] gmailcom> wrote:
> The trouble with the whole xml thing is that it's just another
> enterprisey BS to grind CPUs idle times. You need an xml document, an
> xml document describing the structure of the previous document, yet
> another xml document to describe how to style the original document
> itens, perhaps a xml document describing how to transform your xml
> document into another xml document. It's an insanely verbose and
> homogeneous pile of human and machine barely readable crap.
It's verbose, but it has one advantage over most other formats: It's
standardized and pretty well supported.
It has many advantages over many other formats. One example is character
encoding. With all types of character encodings out there, and support
for them in different file formats and programs being what they are, a
*standardized* form for representing special characters can be really
useful. Also, any program that reads XML ought to support it regardless
of which character encoding it uses (at least if the program uses a
generic XML parser internally).
Compare this to, for example, just a simple raw .txt file. Which encoding
does it use? ISO-Latin-1? ISO-Latin-9? UTF-8? Shift JIS? EUC-JP? ISO-2022-JP?
Something else completely? Impossible to say. With an XML file you don't have
to care. (As said, if your program uses a generic XML parser, the character
encoding used in the input XML file becomes a non-issue.)
Not that this exact same thing wouldn't be possible with a less verbose
format, but as said, XML is widely supported so it has this implicit
advantages over many other formats.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 23/02/2012 20:06, Warp nous fit lire :
> It's verbose, but it has one advantage over most other formats: It's
> standardized and pretty well supported.
>
Well, XML is a container. The problem is lack of intelligent design for
the inside. It is too often the Excel sheet of today: A bunch of
entries, without consistency.
Indeed, with a bit of base64 encapsulation, you could put an BINARY
excel sheet file into a XML document. And advertise that you output XML.
And to make matter more interesting, some find it enterprisey to have
xml inside xml... and other old CSV into XML too (without reinterpreting
the data, so it's just a formatting. A dumb formatting).
> It has many advantages over many other formats. One example is character
> encoding. With all types of character encodings out there, and support
> for them in different file formats and programs being what they are, a
> *standardized* form for representing special characters can be really
> useful. Also, any program that reads XML ought to support it regardless
> of which character encoding it uses (at least if the program uses a
> generic XML parser internally).
Read it, yes. Understand it, that's another whole story!
Same as: I can read latin or japanese in katakana, with few error on
sound. That does not means I get the meaning. At least I can edit it
like a monkey.
> Not that this exact same thing wouldn't be possible with a less verbose
> format, but as said, XML is widely supported so it has this implicit
> advantages over many other formats.
XML is interesting when exchanging documents/data, once the big bosses
and their technical staffs have agreed on a XSD. But whenever you add a
third company, you need to negociate another XSD (with a totally
different approach of the data, not even compatible with the first one).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|
