[
Lists Home |
Date Index |
Thread Index
]
David,
I appreciate your comments. I'll respond to this, then have to focus on
other things.
A CSV, by itself, can be quite problematic, just as you say. The same CSV
used in novel ways in conjunction with grid-objects (e.g., spreadsheets), is
a hyper-efficient data transmission mechanism.
This grid-CSV combination has many other benefits, as well, including
security, semantic navigation, generic analytic modeling, computational
facility, and portability. In addition, this architecture can consume and
generate XML/XHTML (thus being a gateway to XML), accommodate inductive
logic engines, and more.
Since it is not appropriate to discuss the details on this forum, anyone
interested is welcomed to contact me at sbeller@nhds.com.
Steve
-----Original Message-----
From: david.lyon@computergrid.net [mailto:david.lyon@computergrid.net]
Sent: Tuesday, December 07, 2004 4:07 PM
To: xml-dev@lists.xml.org
Subject: RE: [xml-dev] Data streams
Stephen,
Comma seperated Value files are frustrating to use
in production environments.
Just yesterday, I had one IT Help desk person telling
me to that a CSV pricelist file was a CSV Invoice file.
Not even the help desk people can sometimes follow
what is going on with csv.
I don't think there would be much interest for bigger
and better CSV formats because all of the old code
that is there would probably break, and then what
we have now would fall in a screaming heap.
That wouldn't be nice....
Quoting "Stephen E. Beller" <sbeller@nhds.com>:
> <<the expressiveness of CSV files
> was simply too limited to allow for efficient encoding of what we wanted
to
> support in a spreadsheet. While there are tricks to build "expressiveness"
> into a CSV, they can get pretty ugly, large and expensive to process. The
> same "expressiveness" arguments that were used to justify ASN.1 encodings
of
> spreadsheets in the mid-1980's would make good arguments for using XML
today
> instead of CSV.>>
>
> What if there's a way to give a CSV the rich expressiveness of XML when
> dealing with data arrays, and do so in an elegant and efficient way that
> adds little to resource consumption, and provides rapid transmission,
> parsing and rendering?
>
> What if that CSV captured complete data semantics, hierarchical
associations
> between the data elements, and proper serialization?
>
> What if that CSV could be quickly searched and transformed into
interactive
> graphic visualizations offline?
>
> And what if the CSV could be used in conjunction with XML, possibly as a
> powerful alternative to CDATA?
>
> Steve
>
> -----Original Message-----
> From: Bob Wyman [mailto:bob@wyman.us]
> Sent: Monday, December 06, 2004 6:52 PM
> To: david.lyon@computergrid.net; 'Stephen E. Beller'
> Cc: xml-dev@lists.xml.org
> Subject: RE: [xml-dev] Data streams
>
> David Lyon wrote:
> > True. The old parts of Excel are written in assembly language
> > by true masters. They are efficient. The CSV era was at the
> > same time as the assembly language coding.
> But, there were others in those days that were writing tight-code
> but not using CSV... At Digital, we were using binary ASN.1 based
encodings
> to store spreadsheets in the 1980's since the expressiveness of CSV files
> was simply too limited to allow for efficient encoding of what we wanted
to
> support in a spreadsheet. While there are tricks to build "expressiveness"
> into a CSV, they can get pretty ugly, large and expensive to process. The
> same "expressiveness" arguments that were used to justify ASN.1 encodings
of
> spreadsheets in the mid-1980's would make good arguments for using XML
today
> instead of CSV. For instance, the structure of ASN.1 (or XML) makes it
easy
> to do things like distinguish sheets from workbooks or to maintain
multiple
> versions of the data in a single file (resulting in great compression if
> encoded as deltas at the cell or region level!). Also, either ASN.1 or XML
> allow you to vary the types and formatting of rows in your spreadsheet in
> non-uniform ways (i.e. have every cell be a different type/format
> combination). That is hard to do with CSV.
> Another nice thing about XML is that since its model is so similar
> to ASN.1, it's real easy to go one step farther and use a binary encoding
to
> get efficient storage. Expressiveness when needed, compactness when
needed,
> a consistent data-model either way. Today, you can have it your way. Or,
> tomorrow maybe...
>
> bob wyman
>
>
>
>
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
|
