Slashdot Mirror
W3C launches Binary XML Packaging
Spy der Mann writes "Remember the recent discussion on Binary XML? Well, there's news. The W3C just released the specs for XML-binary optimized packaging (XOP). In summary, they take binary data out of the XML, and put it in a separate section using MIME-Multipart. You can read the press release and the testimonials from MS, IBM and BEA."
except SQL isn't very useful when it comes to technologies like RSS say......
if you're using an XML file in a place where you need a high performance SQL database then you're doing something wrong. If you're using XML as datastorage for some small webapp who cares so long as it's fast enough for that particular application.
Photos.
As you point out, it is the wrong tool for the job, much like using tables to layout HTML pages (as the CSS religionists like to point out).
My 64 million dollar question is why they put an acronym inside another acronym: XOP stands for XMLOP? WTF??!!
They REALLY have too much time on their hands!
slashdot: A failed experiment.
This seems like it would be an ideal fit for services such as Flickr as it would allow for image (or other binary media files) to be sent with xml data - in a compressed binary format.
Whatever happened to the virtues of simplicity, like a file containing a header record detailing the field names, and rows containing the data in either fixed-length or delimited form? Damn fast to implement, debug, read from and write to. Parsing? What parsing? Read the first line, split it to get your headers, and read 1 line per record.
Ideal for data exchange. Easy to manipulate via javascript on the client. Simple to display and manipulate via the DOM (Document Object Model). Not resource-hungry. Handles both text and binary data. Dirt easy on the server.
I ran a test to compare, and I'm able to select, format, and serve 1000 records this way in less time than 100 records in simple HTML, never mind xml. By doing this, the client can page through, say, 25 records at a time without having to hit the server every few seconds to see the next/prev pages.
And they're going to do what, say "gzip it" ? The amount of bandwidth and CPU time this wastes is abysmal.
Someone needs to stop these people.
o/~ Join us now and share the software
This is simply a way to reference binary data from within an XML document and to have that binary data included in the same payload (using MIME).
Passing binary data in XML is a big problem. Everybody just invents their own method of doing it (although most are just variations on the theme presented here).
There is a need for this specicification but it is not ground breaking or even particularly /. newsworth.
Really? You can't see the benefit?
N ameLikeThis>
... that will help a lot. People have been clamoring for a STANDARDIZED recommendation for XML for a LONG time.
You mention SVG, but then you fail to see the benefit of reducing the size of, say, a large SVG file in a standards compliant way so that it can be transferred and take up less bandwidth. A good binary standard will DEFINITELY be smaller than the verbosity that is XML. Sure you can compress it, but when you compress a whole bunch of unneeded crap, you still have a whole bunch of unneeded crap... just compressed. If this standard reduces the amount of space it takes to write:
<someLongTagWithANameLikeThis>1</someLongTagWithA
id, parentid, tag, text
1, -, root, yes you can
2, 1, child, it's simple
3, 1, child, do it like you would in actual code
4, 3, grandchild, you don't really think memory has magical trees in it do you?
5, 4, answer, it doesn't
6, 1, child, you can create trees in CSV
==
<root>yes you can
<child>it's simple</child>
<child>do it like you would in actual code
<grandchild>you don't really think memory has magical trees in it do you?
<answer>it doesn't</answer>
</grandchild>
</child>
<child>you can create trees in CSV</child>
</root>
Which one is *really* easier to parse? (Not necessarily read.)
Yes, but this is what ASN1 encoding is for. It's a structured, self-describing encoding scheme that works very well for structured data. What advantages does this binary XML have over ASN1? Both require external descriptions to attach meaning to the data.
In your case, ASN1 is what you should be using, not XML in the first place.
The circle is complete. We started with binary format, moved to XML for readability purposes and then switched XML back to binary for speed.
Obviously someone needs a knock on the head - when you design your application, don't you think about such things as a balance between performance and maintainability first and then implement what is suited better for your specific case? Obviously not! Just a little while ago everyone and their grandmother switched to XML for whatever reason but then they realized: -OMFG, XML processing is processor intensive! I probably shouldn't have handled every single internal type as an XML string that needs parsing and typecasting for every operation. I probably should have used more suitable memory structures for those data structures that are used within the same application on the same computer and not used a gigantic XML just because I can! What to do what to do? OH, I KNOW! Let's change this char based XML into a binary XML, that will make it faster! (It won't make it more human readable, that's for sure.)
So what's next? A char based XML that wraps around a binary XML for readability? A binary wrapper for a char based XML wrapper to a binary wrapper around a char based XML wrapper for recursive processing?
You can't handle the truth.
XML has become at least two things since its evolution:
The interesting part of the story is that #2 came first. Since then, the W3C has recommended the Infoset abstract concept.
For the developers out there, think of how often you parse the "angle brackets" yourself. Most everyone these days (yes, I know there are exceptions) uses an API which presents elements and attributes in a wire-format-agnostic way.
As a developer, I would love to have the option to flip a switch in my code to permit Binary XML. If I can read and use the Infoset in exactly the same way, why would I object to the wire format being binary instead of text? My API is the same, but the transport is more compact and efficient.
Human-readable wire formats are great for debugging during development, but provide no real advantage in production systems (provided there are utilities available to produce human-readable XML from the binary wire format.)
"Power corrupts, and absolute power corrupts absolutely." -- Lord Acton
Amazingly, HTML compatibility was easier before it was "standards" this and "standards" that.
Are you *sure* about that ?
<blink >
<marquee >
<object >
<bgsound >
No-one forces you to validate your html (unless you work for me =). Why I come from it's comformance first, compatibility second.
So, You're Against Innovation?
A common misconception is that folks who advocate HTML validation are retro-thinking, "backwater unix geeks" who stubbornly oppose innovation. It's true that many advocates of HTML validation are indeed seasoned computer professionals, who have learned the hard way that portability and compatibility are key elements to ensuring the longevity of any software product (including Web pages).
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
Not a big deal. You don't necessarily need embedded escape codes (though they work well) - you can also use overflow buckets like databases have used for, say, 30 years
regexes make this easy to implement.
Not necessarily. Master/detail records handle this problem nicely.
No - it's a lot easier to write a function to verify that a postal code is formatted correctly when passed a string, than it is to interface wit a general-purpose verifier. Besides, you still have to verify it independently on the server before saving it (I don't want to run an xml parser every time someone clicks submit).
I create data-driven web apps for a living (i.e. data-driven graphics, UI and text via SVG and HTML), and I firmly believe that XML is the way to go for such creations. It offers a hierarchical structure that is excellent for temporarily storing data pulled from a database, which can then be converted to HTML or SVG or some UI markup (XUL, XForms, or your own thing) via XSLT.
I don't really care that XML is human-readable--I like the fact that because it is extremely well structured, it is therefore easy to create with authoring applications as well as being easy to manipulate real-time by with script (i.e. manipulating its DOM).
I have long wished for a true binary XML spec to make the transmission and parsing/decoding quicker, and this spec isn't it. But I think one day we'll have it, and that won't mean that we've "come full circle" and therefore XML is useless. It just means that we'll have the best of both worlds--speed plus standardized, hierarchical data structures.
Looking for political forums? Check out "The World Forum".