Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: What is XML For?
 Alaric B. Snell wrote: >... >><!ELEMENT purchaseOrder (buyer, seller, ...)> > > > That agrees nothing! It agrees that the buyer precedes the seller and both go within the purchaseOrder. > Do you deny that groups of people get together to produce things like XHTML, > and vertical industry message formats? Because they do. The presence of DTDs > and schemas doesn't remove this requirement. DTDs and schemas give you a structure for _expressing_ your agreement in a human and machine-readable manner. >... > Well, it's just the same with TSV, SQL databases, X.500, LDAP, raw binary > files, and so on. If you take the time to study the history of the problem > you are stating that XML can solve, you will notice that the presence of a > standard formal schema language for a given interchange system makes > relatively little difference. It can be handy to be able to validate stuff > from time to time, but it's no ground breaker. If you provide an invalid PNG > file the program reading the PNG will complain, just as if you provide an > invalid XML document to some XSLT it will barf as soon as it tries to find an > element that's not there. The difference between a) installing a schema and reading its surrounding semantic documenation and b) reading a spec for a binary file format is massive. So massive, in fact, that the XML project is within the means of the average business programmer and the binary project is not. >... > The Internet protocols don't have a formal schema notation, they're just > defined in English in RFCs. And they're more widespread than XML, I reckon; > it hasn't harmed them, has it? Have you ever tried to deploy a new Internet protocol? It is near impossible. That's why there are so few widely deployed ones. Now compare that effort to deploying a new XML vocabulary. Sure, non-XML formats can become popular, as informally specified protocols can become popular. The question is how much effort it takes. This effort greatly impacts the _likelihood_ of the format/protocol gaining popularity. >... > Stop and think about that. What differentiates these products, hmm? Do I buy > Corel because it uses a different in-memory data structure to xfig? Insofar as people buy products in part for their performance, the answer is definately YES. In particular, I find it absurd that you would argue that SAP and Quickbooks should use the same data structures despite the fact that one runs relational-backed enterprises and the other Windows-hosted small businesses. SAP _could not_ get away with using the same datastructures that QuickBooks does. >... >>I'm talking about vector graphics programs. You're talking about bitmap >>apps. > > > Yep, just because I know more about bitmap file formats - overall, we are > discussing data interchange in general; you brought up vector files as an > example, I bring up bitmap files. You well know that almost nobody proposes to use XML for bitmaps. Furthermore, vector graphics provide many more opportunities for optimization based on intelligent choice of data structures. I have a friend who built a commercially successful graphics program around a _single_ proprietary vector graphics algorithm/datastructure pair. It allowed certain kinds of scaling that were impossible with the more traditional algorithms. And in fact this is a very common case in the 3D graphics world. >... > Read what I said before flying off the spout with something irrelevant :-) > > "...into memory as a character array..." > > Not a *byte* array! So the on-disk representation is _different than_ the in-memory representation. And some people will choose to use UTF-8, some will choose to use UTF-2 and some will choose to use UCS-4 for their in-memory representations. And those are all equally valid choices. The in-memory implementation should not be tied to the on-disk representation unless that happens to be convenient. >... > We'd go to the tecchies of the company we were setting up the interchange > with and say "We can accept bog standard CSV or TSV with the following column > headings, or XML with this schema. What do you want to make?" and they'd say > "Um... we'll send a CSV, thanks". We didn't even bother offering to send > people XML, they always wanted something they could just import directly into > applications, and CSV is wider supported than XML - it's been around a lot > longer. In my experience it is painful and obfuscatory to use CSV for hierarchical or linked information. But if you and your customers enjoy it, then I'm glad you're using what works for you. Paul Prescod 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
