Re: The impact of data format selection on application development
John Cowan <[email protected]>
| Newsgroups | gmane.text.xml.devel |
|---|---|
| Message-ID | <CABzTEQCDa_BjhB_NdG8GycM6uLv2yC_fYy=b7emDaoc+XOnRMQ@mail.gmail.com> |
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 <[email protected]> wrote: > > On Sun, Jul 10, 2022 at 10:54 AM Roger L Costello <[email protected]> > 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? >