yet XHTML is still XML, nacho!
yet XHTML is still XML, nacho!
and yet XML is not XHTMLOriginally Posted by momos
Originally Posted by psyon
Nope, you described the length of the data - you didnt describe what the data represents. That 4 bytes could represent anything, int, char etc so its still ambigious.
With XML you are describing what the data represents ...
that's the I fit in my t-shirt, my t-shirt fits into my bag, so I fit in my bag story, bonefry
In my eyes, XML has one strength, verbosity. Every other strength that ever gets cited, is only a due to its various platform support.
One idea I have discussed with a few people, is a "compiled" XML. Maybe a project has already been done, maybe its how Binary XML works (never really looked). Basically, a "compiler" could read the XML data as it is now. Generate a table of tags, and assign each an ID. The document would be filled with more of a byte code to represent the data. You could do something like:
0xa0 == Start Tag
0xa1 == End Tag
Just using those to examples a file might have 0x0a followed by 2 bytes (im assuming 65000+ tags is enough) representing the Tag ID which would be looked up from the table at the start of the file. The next byte could be a flag describing if the tag contains data or more tags within it. If the tag encapsulates data, there will be an integer (or double?) following to tell the lenght of the data, followed by the data. If there are child nodes, they would just follow, each starting with its own 0xa0 to start the chain over.
Please keep in mind I havent put ALOT of thought into the idea, just briefly here and there. A solution like the above would allow XML to be precompiled before being sent for processing. It could help reduce the load on web based service providers. On the other hand, the XML could be decompiled so that it is human readable, and editable where need be.
Anyways, its just a thought.
How's that ? No, not really.Originally Posted by psyon
If you want to reduce the load, work with a database that can import and export XML.
Also, you are giving away XML's greatest streangh: portability.
And you want to throw all that away, and for what ? How often have you had problems with big XML loads ?
You have a big point with portability.Originally Posted by bonefry
But we do have problems with load at my company. We use XML to transport transactions and their images from system to system and one thing we came about with XML is that it's the weakness is the ratio of the space taken by the markup against the actual data. Even if compressing the stream can help with that I had in mind something similar where you'd change the encoding to something shorter (sort-of a XML based compression). So for example, instead of having:
you would have something like:Code:<orders> <order id="1"> <customer> <name>Myrdhrin</name> <billto.address> <address>123 somestreet</address> <city>a city</city> <country>thebestcountryintheworld</country> </billto.address> <shipto.address> <address>123 somestreet</address> <city>a city</city> <country>thebestcountryintheworld</country> </shipto.address> </customer> <items> <item id="1"> <catalog.code>FR23432423</catalog.code> <quantity>1.25</quantity> </item> <item id="2"> <catalog.code>ID234234sd</catalog.code> <quantity>4</quantity> </item> <item id="3"> <catalog.code>Q23423</catalog.code> <quantity>6</quantity> </item> <item id="4"> <catalog.code>T34534534</catalog.code> <quantity>2</quantity> </item> </items> </order> <order id="2"> <customer> <name>sitepoint</name> <billto.address> <address>123 somestreet</address> <city>a city</city> <country>thebestcountryintheworld</country> </billto.address> <shipto.address> <address>123 somestreet</address> <city>a city</city> <country>thebestcountryintheworld</country> </shipto.address> </customer> <items> <item id="1"> <catalog.code>s23sdaf432423</catalog.code> <quantity>15</quantity> </item> <item id="2"> <catalog.code>I2134213434234s</catalog.code> <quantity>5</quantity> </item> </items> </order> </orders>
Code:<orders xmlns:x="http://www.somewhere.test/compression.xsd"> <x:map> <x:a ref="order"/> <x:b ref="customer"/> <x:c ref="name"/> <x:d ref="billto.address"/> <x:e ref="address"/> <x:f ref="city"/> <x:g ref="country"/> <x:h ref="shipto.address"/> <x:i ref="items"/> <x:j ref="item"/> <x:k ref="catalog.code"/> <x:l ref="quantity"/> </x:map> <a id="1"> <b> <c>Myrdhrin</c> <d> <e>123 somestreet</e> <f>a city</f> <g>thebestcountryintheworld</g> </d> <h> <e>123 somestreet</e> <f>a city</f> <g>thebestcountryintheworld</g> </h> </b> <i> <j id="1"> <k>FR23432423</k> <l>1.25</l> </j> <j id="2"> <k>ID234234sd</k> <l>4</l> </j> <j id="3"> <k>Q23423</k> <l>6</l> </j> <j id="4"> <k>T34534534</k> <l>2</l> </j> </i> </a> <a id="2"> <b> <c>sitepoint</c> <d> <e>123 somestreet</e> <f>a city</f> <g>thebestcountryintheworld</g> </d> <h> <e>123 somestreet</e> <f>a city</f> <g>thebestcountryintheworld</g> </h> </b> <i> <j id="1"> <k>s23sdaf432423</k> <l>15</l> </j> <j id="2"> <k>I2134213434234sd</k> <l>5</l> </j> </i> </a> </orders>
I suggest that for the cases where verbosity is causing load factors, one might consider YAML which is rather well suited to over-the-wire exhcange. Another compact format for that is JSON. The main problem with these two is that there aren't enough platforms or variety of implementations of serializers/deserializers, at least compared to XML -- and they don't do the same thing as XML.
IMO, XML's big win is schemas (or DTD's if you are old-school). Unfortunately, there are not yet enough canonical standards to point to schemas as a complete win, but there are some very useful standards already in wide use. There is also the issue of namespaces, which even today some tools do not observe. That said, I think XML is a fine technology that has helped mature the field of data exchange and representation.
And in cases where XML is used in requests? Would you suggest a person imports the XML into the database to parse it?Originally Posted by bonefry
Its only a strength because it was adopted. If any other format were adopted, im sure there would be parsers for every platform also. Besides, with what I suggested, the "compiled" form of the xml could be reversed back into standard text based xml to be sent to platforms with only the normal xml supportOriginally Posted by bonefry
Often enough. When your only dealing in a few thousand transactions a day, its not really an issue, but when you start to get into processing millions of SOAP requests or something, the load can be quite high.Originally Posted by bonefry
Well, I know what you're talking about and you are right, but unless your boss forces you to use SOAP you really have better alternativesOriginally Posted by psyon
No, you're not right about this. Think of CORBA and it's IDL. It's a binary format right ? Only one group activelly maintains it, so you can think of it as a standard. And yet there are BIG differences between different vendors.Originally Posted by psyon
When the format is in binary form it is easy for big fat evil stupid players in the market (Microsoft) to mess with the standards. And their monopolly allows them to push their non-standard way in the market. And who can afford not being compatible with ... (Microsoft) ?
And even XML based languages like SOAP are still not 100% compatible between paltforms. They are giving speaches for years about Java-.NET interop, but even now it is not a reallity.
XML by being simple and human readable and supported by W3C it is harder to mess with it.
Whether something is binary or text is really irrelevant -- consider how CSS and HTML are supported by browser vendors. Microsoft fragmented the market despite these being "text" based standards. Microsoft appears to be bent on preventing the proliferation of open standards; short of government regulation, nothing can particularly prevent that. I think it is safe to say that a published binary standard is equivalent to a published text standard. Of course, text is easier to deal with, all-in-all -- but that doesn't mean it is always the best choice for data-interchange.Originally Posted by bonefry
More importantly, I think you are mixing the idea of syntax and semantics here. XML really only defines the syntax for the data format -- it does nothing about describing the actual semantic structures that are to be used for particular document classes. As you are well aware, these are relegated to DTD's and schemas and there are precious few of these that have been both standardized and accepted/adopted. Certainly some of them are poster-boy successes. Still, many, many mundane application tasks that require data interchange have not been standardized. As a result, there is a proliferation of disparate proprietary/closed/one-off formats that are based on XML syntax. We've saved the lexing, but as wonderful as it is, XML alone does not solve the problem of seamless data-interchange. We still have to write applications that talk in the appropriate formats of the interchanged data.
Advantages of vulnerability in XML-RPC for PHP for hackers
That can be used in order to hack kinds of CMS and weblogs,
Last edited by abalfazl; Aug 16, 2005 at 09:14.
XML Enhancements for Java:
Documents get smart :
XML is csv for dummies. You have to include the field name for every piece of data? Isn't that a redundancy, and a waste of time?
You can always program against csv if you can program, field order is not a problem unless you don't scan the header line beforehand. XML offends one's sense of proportion. The human readibility sells XML to the operational folks who open the files to check them out. It foolproofs, but geez it is so verbose, I hate using these massive things, suppose with 2005 chip speeds this is no longer a problem.
Well foolproofing maybe is a good idea, I certainly have benefitted from dumbing done fast C++ to slow Java. You don't have to think as hard. Ah the heck with csv, it sucks too. Unicode data - ugh. Binary rules. But you can't read it. Your less-techie co-workers want to be able to look and understand, since they've been burnt by bad programming all too often. The 90's for programming was like the 10's for the auto industry, lots of failure. Some picturesque antiques, but underpowered and awkward.
Originally Posted by Koebelin
CSV is not heirarchial, whereas xml is.
There's really no clean way to represent a 5 level deep tree in a CSV format.
XML isn't always the best way to store data, but it's a good way to do it. The biggest strength that it has, as I see it, is that it's self-describing, and "common".
Most modern & emerging standards are xml applications:
Arguing for or against it is really a moot point; it *is* where technolgy is, and where it's going to remain for many years to come. That's life.
You're missing one important point here: XML is not a data transfer format, it is a data markup format. It wasn't intended for transfer of data (and especially not for efficient transfer of data), bit for marking up what each part of the data is suposed to represent.Originally Posted by Koebelin
Now, people have started using XML for transfer of data as well, but it just proves its inherent versability, not its original purpose. Yes, XML files can be as large as hell, and if that goes in the way of your applications' needs d not use XML by any means.
Also note that XML is not a language in itself, despite the name -- it is like a syntax to define languages with. So far we have seen XML being used to define languages for GUI description (XHTML, XUL, XAML), data transfer (RSS), procedural programming (VoiceXML), functional programming (XSLT), remote procedure requests (XML-RPC, SOAP) and a whole bunch of different concepts.