 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Invisible <voi### [at] dev null> wrote:
>> For every single entity you want to use.
>
>> For every individual XML document you ever write.
>
> You don't have to type them manually every time. Text editors support this
> thing called copying&pasting. It can even be used to copy text from one
> document to another.
Sure. If you already have another document to hand with all the entities
in it. It just means that every time you want to write some XML, you've
got to past 8 KB of definitions in at the top. (Or manually figure out
which ones you actually need in this particular document, and chop out
the rest.)
It's just rather messy.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] devnull> wrote:
> It just means that every time you want to write some XML, you've
> got to past 8 KB of definitions in at the top.
What do you need 300 symbols for? Could you even remember that many?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
And lo On Fri, 19 Mar 2010 16:14:27 -0000, Warp <war### [at] tagpovrayorg> did
spake thusly:
> Invisible <voi### [at] devnull> wrote:
>> It just means that every time you want to write some XML, you've
>> got to past 8 KB of definitions in at the top.
>
> What do you need 300 symbols for? Could you even remember that many?
Why even bother with copy&paste? Just create one schema with the
definitions in it and just reference it in any xml document. Of course
you'd have to use it as an element rather than an entity.
--
Phil Cook
--
I once tried to be apathetic, but I just couldn't be bothered
http://flipc.blogspot.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"gregjohn" <pte### [at] yahoocom> schrieb im Newsbeitrag
news:web.4ba35bf7c9c03e2434d207310@news.povray.org...
> Please no one GIYF me! :)
Well, I hate those GIFY-guys, too. If I ask something it is usually because
I did not find the info I was looking for - for whatever reason
(misspelling, being swamped with useless information from Google, being too
lazy to learn the povray-manual by heart - mea culpa ;-). If somebody knows
he should tell what to search for or simply ignore me.
Back to your topic ;-)
XML is a data-format that can be very easily ported across platforms. That's
it - no more, no less. Actually this is quite a lot ;-) If you need not
worry whether your INT has 16, 32 or 64 bits (and so on) - this has a
certain appeal. It is human-readable in theory; in practise you need an
editor to do anything complex. Still - a config-file in xml is much more
easily edited than one in a custom binary-format.
Raw XML-coded data makes for very large files, which >was< an issue 10 years
ago. Your average harddisk had a capacity of 300 MB (note: MB, not GB ;-)
and zipping took much longer on slow computers then. Nowadays you just gzip
your XML-file and a google-sitemap shrinks from 300 kB down to a measly 6
kB.
IF Microsoft would have had better support of XML and XSLT (which is a
stylesheet language for XML and in XML) in their early browser versions,
most webpages today would be written in XML and XSLT, I guess. In fact, most
CMS-based sites probably are, but instead of using XML and XSLT directly and
letting the browser do the necessary transforms you use XSLT to transform
into HTML, which is better supported on older browsers. You have to have
>some< for very old browsers in every commercial website, if you like it or
not. The higher ranking the CEO, th more he is bound to cling to Internet
Explorer 5.0 - though, to be fair, the more progressive ones use IE 6.0.
Which they usually view on their high-res 24"-TFT monitor which is set to a
resolution of 800 x 600, so they can "see" better. Unfortunately "Rita" from
"Working Daze" seems to be everywhere - but I digress.
I personally used XML and XSLT about five years ago to create an off-line
CMS for a webshop using the then new VB Express 2005. Use MS-Access to store
the data, use program to create an in-memory xml-file and use xslt to
transform it to static HTML. Upload output to server or to CD and be done.
It had German and English output (you just had to write the respective
XSLT-files) and would have been easily portable to other languages.
IMO: XML is probably the future. It would be nice if there were more
standardized XML-based data-formats (or namespaces) around, so you could use
ONE file to upload your catalogues to any marketplace on the web. It would
be nice, too, if those in existence were better supported, like SVG. Ever
tried to port complex SVG from Inkscape to any other graphics editor of your
choice?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
TC wrote:
> XML is a data-format that can be very easily ported across platforms.
Not really even that.
> worry whether your INT has 16, 32 or 64 bits (and so on)
You always have to worry about that. It's just a question of whether your
encoding tells you that or not.
> t is human-readable in theory; in practise you need an
> editor to do anything complex.
In practice, all this means is that people have stopped bothering to
document data formats. I can't tell you the number of times I've said "can
you send me the scema?" and they answer "We can send you some examples."
> Still - a config-file in xml is much more
> easily edited than one in a custom binary-format.
There are better formats for that, too. You're talking about the benefits of
small files intended to be edited by hand being encoded in ASCII, rather
than the benefits of XML per se.
> Raw XML-coded data makes for very large files, which >was< an issue 10 years
> ago.
It still is. We don't use XML for Call Data Records, 1032 records (the
records bank transactions and ATMs use), or SNMP or syslog. You don't want
to be transporting XML over SMS messages to make your program work.
> IF Microsoft would have had better support of XML and XSLT (which is a
> stylesheet language for XML and in XML) in their early browser versions,
I'm pretty sure IE5 predated XSLT.
In any case, that's *markup*. That's what it's for.
My opinion is that if you have more text between < and > than you
do between > and < then you're clearly using the wrong tool. Try ASN.1 or
something, which has a readable version isomorphic to a very space-efficient
binary version which is isomorphic to the speed-efficient binary version. Or
at least JSON or INI or some such.
The whole crap of "human readable" is bogus. None of it is human readable.
You at least need a text editor. Given that, you could probably write VI and
emacs macros to edit binary ASN.1 formats as text, just like you do brace
matching nowadays.
The only real advantage of using it for data is that every language in the
world has support for at least primitive XML parsing, so it's easy to
serialize a tree of text.
--
Darren New, San Diego CA, USA (PST)
Yes, we're traveling togeher,
but to different destinations.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> In any case, that's *markup*. That's what it's for.
>
> My opinion is that if you have more text between < and > than you
> do between > and < then you're clearly using the wrong tool. Try ASN.1 or
> something, which has a readable version isomorphic to a very
> space-efficient binary version which is isomorphic to the speed-efficient
> binary version. Or at least JSON or INI or some such.
Me in the ##c++ IRC channel:
<PovAddict> quotemstr: this is what the original looks like:
http://codepad.org/bpZ6wWJq
<quotemstr> PovAddict: Ew.
<Kermos> PovAddict: WTF is that?
<PovAddict> Kermos: writing some XML :)
<PovAddict> now have the guts to say *my* code was stupid :P
<Kermos> ....
<quotemstr> There are degrees of stupid.
<Kermos> quotemstr: I think that one is off the scale
<JordiGH> PovAddict: Lord have mercy should you forget one line or miscount.
Their "WTF??" was mostly about the C++ code, not the XML being generated,
but I think the same reaction would apply to that.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I'm pretty sure IE5 predated XSLT.
I was talking about the need for backward compatibiliy and MS compatibility
(vs. any true standard) when tring to get a website on-line, not about xml
in general. Maybe I was not that clear. Somebody in chare is bound to have
some stone-age browser installed and to complain loudly. I am so sick of
this...
BTW: IE5 had XML and XSL support. Microsoft-style, at least. If you don't
believe me, look at this:
http://www.amazon.com/XML-Programmers-Reference-Alex-Homer/dp/1861001576/ref=sr_1_1?ie=UTF8
> The whole crap of "human readable" is bogus. None of it is human readable.
Yes and no. Depends on what you want to do. Here's a bit from the start of
some CIV4 xml-file, which I'd call human readable, intuitively
understandable and easy to modify. I could be done in different ways, too,
of course.
<Civ4ArtDefines xmlns="x-schema:CIV4ArtDefinesSchema.xml">
<MovieArtInfos>
<MovieArtInfo>
<Type>ART_DEF_MOVIE_INTRO</Type>
<Path>Assets/Art/Movies/Intros/intro.bik</Path>
</MovieArtInfo>
...
>You at least need a text editor. Given that, you could probably write VI
>and
Given your definition povray SDL is not human readable, too. You need at
least a text editor ;-)
> The only real advantage of using it for data is that every language in the
> world has support for at least primitive XML parsing, so it's easy to
> serialize a tree of text.
YES! And that's exactly the reason I use it (when I use it). It is
convenient, provided you have enough space and computing power.
BTW: Your post made me realize how much our field of view becomes narrowed
down to our line of work. For me it's websites and small utility-programs
that can be cooked up in a few days. So nowadays in my work I usually have
sufficient computing power and hdd-space galore. But if you want to transfer
data via SMS, XML is NOT a good way of doing things, of course. ;-)
Don't get me wrong. I am no fan of XML. But I have seen worse. And you are
right about the general lack of documentation for data-file-formats. But
even if you have the docs, you still need to write code to actually read and
parse the files - with XML (and thanks to the extensive XML-support in many
programming languages) I find it comparatively easy to read,write and modify
third-party data-files which are done in XML.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
TC wrote:
>> The whole crap of "human readable" is bogus. None of it is human readable.
> Yes and no. Depends on what you want to do.
You miss my point. Punched cards are human readable. ASCII stored on a hard
disk is not. To read ASCII stored on a hard disk, you need software that
interprets the bit paterns and puts them on the screen as glyphs from a
particular font.
> <Civ4ArtDefines xmlns="x-schema:CIV4ArtDefinesSchema.xml">
> <MovieArtInfos>
> <MovieArtInfo>
> <Type>ART_DEF_MOVIE_INTRO</Type>
> <Path>Assets/Art/Movies/Intros/intro.bik</Path>
> </MovieArtInfo>
Can Path and Type come in any order? What are the valid values for Type? How
many movieartinfo blocks can you have in one movieartinfos.
See? Not human readable enough.
> Given your definition povray SDL is not human readable, too. You need at
> least a text editor ;-)
Yes. So the "human readable" doesn't mean that. It means "readable with
ubiquitous tools." The problem with using something like ASN.1 is not that
it isn't "human readable", but that the tools to turn it into "human
readable" aren't ubiquitous. Of course, if you work in an industry where
standards are based on ASN.1, then the tools *are* ubiquitous, so it's as
human readable as any other format.
> BTW: Your post made me realize how much our field of view becomes narrowed
> down to our line of work. For me it's websites and small utility-programs
> that can be cooked up in a few days. So nowadays in my work I usually have
> sufficient computing power and hdd-space galore. But if you want to transfer
> data via SMS, XML is NOT a good way of doing things, of course. ;-)
Yeah. Unfortunately, people start putting it in inappropriate places, or
they think their home-brew POS parser is actually usable.
One advantage of XML over lots of other stuff is that there are no length
counts, so you can futz with a plain text editor to make it work.
> Don't getme wrong. I am no fan of XML. But I have seen worse. And you are
> right about the general lack of documentation for data-file-formats. But
> even if you have the docs, you still need to write code to actually read and
> parse the files - with XML (and thanks to the extensive XML-support in many
> programming languages) I find it comparatively easy to read,write and modify
> third-party data-files which are done in XML.
As long as the other side actually follows the standard and parses stuff
according to the spec, instead of a half-assed
open-source-works-for-me-I-don't-care-about-you hackware library.
--
Darren New, San Diego CA, USA (PST)
Yes, we're traveling togeher,
but to different destinations.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"TC" <do-not-reply@i-do get-enough-spam-already-2498.com> wrote:
>> I'm pretty sure IE5 predated XSLT.
>
> I was talking about the need for backward compatibiliy and MS
> compatibility (vs. any true standard) when tring to get a website on-line,
> not about xml in general. Maybe I was not that clear. Somebody in chare is
> bound to have some stone-age browser installed and to complain loudly. I
> am so sick of this...
>
> BTW: IE5 had XML and XSL support. Microsoft-style, at least.
Last time I tried (which is long ago), IE had better XSLT support than
Firefox. That may have changed, though.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez <nic### [at] gmailcom> wrote:
> Last time I tried (which is long ago), IE had better XSLT support than
> Firefox. That may have changed, though.
Why is it that almost always when someone says "last time I tried" (in
relation to software), they mean something like "10 years ago"? It's not
very relevant, you know... :)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
