In article <405ca493@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   What I wonder is this: If XML is not intended to be written and read
> by humans, then why make it so bloated? Why not make a compact binary
> format instead?

Because it's harder to read and write binary data in a portable way. 
However, there's no reason that it couldn't be a compact ASCII format. 
YAML, for example, is very easy to read, is compact, and no more 
difficult to parse or write:
http://yaml.org/start.html


>   Imagine for example an image format in XML. What the h*** would be the
> idea with that?

http://www.w3.org/TR/SVG/

"This specification defines the features and syntax for Scalable Vector 
Graphics (SVG) Version 1.1, a modularized language for describing 
two-dimensional vector and mixed vector/raster graphics in XML."

I thought it sounded great...up until that last part.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

"Thorsten Froehlich" <tho### [at] trfde> wrote in
news:405c0e14@news.povray.org: 

> XML/XSLT are a late internet-bubble hype
> that create bloated, slow and complex programs in absolutely every
> place they have ever been used.  Consequently, every responsible
> designer and programmer should avoid this combination like the plague!
>  They are no good for anything they have ever been used for.  
> 
> Consequently, even the suggestion to use XML is a total waste of time!
> 
>     Thorsten
> 

I agree wholeheartedly in the case of SDL.  However, for the IMPFarm, XML 
was a very good fit.  It provided an easy way issue rendertasks from a 
database at the webserver to then be parsed at the client in perl.  
Switching to XML simplified the code significantly.

-- 
Tom
_________________________________
The Internet Movie Project
http://www.imp.org/

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> >   Imagine for example an image format in XML. What the h*** would be the
> > idea with that?

> Err, doesn't JPEG2000 encode the image in XML? Or at least some of it? :-)

  The header perhaps (which I think it's a completely braindead idea),
not the whole thing.
  If the whole thing was made with XML, each pixel would be its own
tag and each color component value would be an attribute of that tag.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Christopher James Huff wrote:

> http://www.w3.org/TR/SVG/
> 
> "This specification defines the features and syntax for Scalable Vector 
> Graphics (SVG) Version 1.1, a modularized language for describing 
> two-dimensional vector and mixed vector/raster graphics in XML."
> 
> I thought it sounded great...up until that last part.
> 

Perhaps you should have read further. Adding a raster in SVG means 
including images the same way html does using an image tag. Add
a few filter effects and thats it.

Dave

Post a reply to this message

In article <405cdbae@news.povray.org>, Darren New <dne### [at] sanrrcom> 
wrote:

> Christopher James Huff wrote:
> > Because it's harder to read and write binary data in a portable way. 
> 
> No it's not.

Hmm...yes it is. To write "1.5" in a portable way in text only requires 
writing those three characters. In binary you need to write it byte by 
byte in a known floating point format and byte ordering, regardless of 
what the native machine format is.


> I'd even go so far as to bet there are more uses of 
> portable binary formats than portable text-based formats, once you get 
> off the internet.

They certainly are more useful, but that doesn/t make them any easier to 
read and write.


> Try ASN.1, for example. And I only know of two image 
> formats that aren't binary, and neither is designed to be read by a 
> person, yet all are quite portable. You just have to specify stuff like 
> the order and size of multi-byte integers.

You forget floating point values, but even multi-byte integers involve 
more complexity than text format integers.


> Anyway, XML *is* a binary format. It's UTF-8 by default.

UTF-8 is an encoding for text. XML is text. You can't directly write a 
binary floating point value in it, for example...you have to convert it 
to a human-readable textual form, even if it'll never be seen by humans. 
This is trivial to do with the standard C or C++ libraries, but there 
are no standard ways to portably write multi-byte integers or floating 
point values. You have to write all that stuff yourself.


> > I thought it sounded great...up until that last part.
> 
> Or, as I saw someone say elsewhere, XML is a hammer looking for a 
> nail... and finding fingers.

Sounds appropriate.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

In article <405da779@news.povray.org>,
 David Burnett <var### [at] ntlworldcom> wrote:

> Perhaps you should have read further. Adding a raster in SVG means 
> including images the same way html does using an image tag. Add
> a few filter effects and thats it.

I don't care about the means of including raster graphics, it's the 
"graphics in XML" part that I object to. If there were no mechanism for 
including raster images, I would still object to the XML.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

In article <cjameshuff-FC8E81.10072721032004@news.povray.org> , Christopher
James Huff <cja### [at] earthlinknet>  wrote:

>> Christopher James Huff wrote:
>> > Because it's harder to read and write binary data in a portable way.
>>
>> No it's not.
>
> Hmm...yes it is. To write "1.5" in a portable way in text only requires
> writing those three characters. In binary you need to write it byte by
> byte in a known floating point format and byte ordering, regardless of
> what the native machine format is.

This is simply not correct.  You can perfectly represent a floating-point
number with two integers.  In fact, a floating-point number is exactly that!
Consequently, representing it as text gains you nothing except the false
impression that you can get an exact value representation.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In article <405dd981$1@news.povray.org>,
 "Thorsten Froehlich" <tho### [at] trfde> wrote:

> > Hmm...yes it is. To write "1.5" in a portable way in text only requires
> > writing those three characters. In binary you need to write it byte by
> > byte in a known floating point format and byte ordering, regardless of
> > what the native machine format is.
> 
> This is simply not correct.  You can perfectly represent a floating-point
> number with two integers.  In fact, a floating-point number is exactly that!
> Consequently, representing it as text gains you nothing except the false
> impression that you can get an exact value representation.

Floating point numbers are a bit more than a simple ratio, they are 
usually a binary version of scientific notation. The most common form 
uses a sign bit, a normalized mantissa, and a biased exponent. The 
allocation of individual bits and the actual layout can vary. While the 
text representation may not exactly match the internal value, it will be 
written and read the same way on any platform, which is not guaranteed 
for floating point values in binary files. For that, you must explicitly 
define the layout and write your own code for reading and writing binary 
float values. This isn't very difficult, but it is another step to take.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

In article <cjameshuff-624FE6.13452321032004@news.povray.org> , Christopher
James Huff <cja### [at] earthlinknet>  wrote:

> Floating point numbers are a bit more than a simple ratio, they are
> usually a binary version of scientific notation. The most common form
> uses a sign bit, a normalized mantissa, and a biased exponent. The
> allocation of individual bits and the actual layout can vary.

When and where did I say something about "a simple ratio", and why should I?
You are missing that fraction and exponent are integers, and "conversion" to
a less precise representation either yields an overflow/underflow or a
match.  Nothing else happens in hardware when dealing with single and double
precision floats, in fact.  If you want to do no work at all, just define
the fraction as 64 bit integer and the exponent as 16 bit integer.  Then you
just shift to get your favorite floating-point representation.  Double both
and you can even support 128 bit IEEE 754 floats easily!  Not to mention the
old VAX float format uses exactly the same concept.

On the other hand, all architectures that used non-IEEE 754 float formats
are dead today, and the systems still out there are not used for any new
software but only to run old legacy programs not worth porting.  So in fact,
all you really need to deal with is IEEE 754 float byte order, which is
trivial of course.

All you did was fall for the pseudo benefits frequently mentioned by XML
advocates.  What they never say is that the problems they are trying to
solve have never been problems or solved decades ago.  Still, if I would
sell software, I would also claim a format that requires users to upgrade
both hardware and software to use it solves all of users' problem.  In fact,
the only problem is that a few big companies define binary file formats and
then do not both to specify them to lock out competitors or make migration
difficult.  So they promise XML could "solve" this problem, which is of
course cannot.  They will just move on and change the DTD with every new
version.

A perfect example is the M$ Visual Studio "XML" project format.  Even minor
upgrades from 7.0 to 7.1 cannot be reversed, nor can it read files when a
third-party compiler (Intel's) has been used and is not present everywhere.
Thus, except complaining quickly about (frequently needed) errors in manual
changes to the content and rejecting the file completely because it does not
validate (without saying what is wrong, of course), this use of XML is a
perfect example why XML is the most useless invention since the rectangular
wheel.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In article <405dfd16$1@news.povray.org>, Darren New <dne### [at] sanrrcom> 
wrote:

> Christopher James Huff wrote:
> > Hmm...yes it is. To write "1.5" in a portable way in text only requires 
> > writing those three characters.
> 
> Along with a flag that says it's three characters.

No. You just have to say "write this float". The C and C++ standard 
libraries already have the capability of doing this. "strm << floatVal;" 
is a lot easier than writing your own function or tracking down some 
library to do it.


> And how do you think you get a floating-point 1.5 into those three 
> characters? :-)

By calling the appropriate standard function.


> The fact that it's built into the language doesn't make 
> it easier. It just makes it built in.

It does make it easier. If it's already there, you don't have to write 
it.


> I disagree. See above. Text formatting of integers is built into the 
> language. Try to output that 1.5 using nothing but putc() and knowing 
> nothing about the internal representation of floats, and you'll find 
> it's not as simple as you think. You tend to get things like 
> 1.499999999978 and you have to know the actual binary size of your 
> floating point numbers anyway in order to stop at the right place.

Of course it's harder if you do it the hard way. My point is that 
there's an existing easy way, which doesn't exist for binary data. And 
you lose information in the base conversion...but there's no guarantee 
the native format on a foreign machine will be the same anyway. You get 
something that works for almost everything with very little effort, and 
most people stop there.


> Well, actually, there is. ntoh() and hton(), Sun's XDR libraries, any 
> ASN.1 library, etc etc. Plus, move to any language that's actually been 
> invented in the last 20 years or so, and it probably has libraries for 
> doing this.

ntoh() and hton() don't appear to be standard. Sun's XDR libraries are 
Sun's, you gotta go get them. I know it's a pretty much solved problem, 
and was never very difficult, but it is still one more hurdle to go 
over. And many projects (like POV) use C or C++, moving to a language 
that has standard support is not always practical. This is one of my 
peeves about C/C++...any language I design that has file I/O will be 
able to read and write floats and integers in a platform independent way.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message