OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] What is XML For?

[ Lists Home | Date Index | Thread Index ]

Alaric B. Snell wrote:

>><!ELEMENT purchaseOrder (buyer, seller, ...)>
> That agrees nothing!

It agrees that the buyer precedes the seller and both go within the 

> 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
> 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


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS