Re: [xml-dev] The impact of data format selection on application develop

A specific CSV file, perhaps not. But If you want to handle all the cases in that RFC, you either need to use a CSV library or suffer the possible consequences, just as in XML or HTML.

Note that the \ escape is not part of CSV: that belongs to a related format I'll call "DSV" (delimiter separated value) which is parameterized by the delimiter. CSV uses double quotes to surround a field containing comma or newline, and so cannot be processed line by line.

On Sun, Jul 10, 2022 at 11:17 AM Ihe Onwuka <ihe.onwuka@gmail.com> wrote:

On Sun, Jul 10, 2022 at 10:54 AM Roger L Costello <costello@mitre.org> wrote:
Michael Kay quite correctly noted that the specification of my hypothetical data format is incomplete. Please, allow me to add a sentence or two to address its inadequacies:

The data format consists of lines (lines are strings that are typically separated by newlines, although the user may use a symbol other than newline, if desired). Each line contains fields. Fields are ASCII strings. Fields are separated by a delimiter (common delimiters include the tab, space, or comma symbol, although the user is free to use another symbol if desired). Fields may contain the field delimiter symbol provided the symbol is preceded by a backslash symbol (this is called "escaping the symbol"). Fields may be empty. Each line has the same number of fields.

Admittedly, those additions do result in using more ink to specify the data format. Nonetheless, it is a far cry from the dense 36 pages of the XML specification plus the 16 pages of the namespace specification. I think the data format can be fully understood in less than 30 seconds. Contrast with gaining a full understanding of the XML data format, which may take months or even years.

Thanks for the comments Michael!

/Roger

So do you think reading and comprehending the CSV technical standard RFC is a prerequisite for using a CSV representation for a simple piece of data?