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