Media Type "text/csv": new draft (-02) and Last Call
clyde.ingram at edl.uk.eds.com
clyde.ingram at edl.uk.eds.com
Thu Mar 31 22:04:51 CEST 2005
Yakov,
That draft wording sounds excellent.
Now, if you were to ALSO mandate the presence of the header record, that
would mitigate my concern that computer applications should be able to
exchange CSV files without worrying about same field order (simply because
the header conveys the field names, rather than needing an out-of-band,
bilateral agreement). And, of course, presence of a header record lets a
computer application determine immediately whether the supplied fields are
likely to be what it expects. All good aids for careful validation.
Thank-you,
Clyde
-----Original Message-----
From: Yakov Shafranovich [mailto:research at solidmatrix.com]
Sent: Wednesday, March 30, 2005 8:08 PM
To: clyde.ingram at edl.uk.eds.com
Cc: GK-lists at ninebynine.org; ietf-types at alvestrand.no
Subject: Re: Media Type "text/csv": new draft (-02) and Last Call
clyde.ingram at edl.uk.eds.com wrote:
>
> But the same cannot be said of automated computer-based applications,
> where maintaining a strict count of generated and expected
> Comma-Separated-Values per record is not only easy, but also allows for
> an extra level of data validation: namely that a received record is
> corrupt if it has too few or too many fields. This is where
> standardisation in the format of the CSV records becomes appropriate
> material for an RFC.
>
The draft as it is written now (-03) does not mandate that the same
number of fields need to appear on each line, mainly due to the fact
that the draft is focusing on the MIME type registration. Would the
following change to section 2, subsection 4 be sufficient to address
your concerns:
"Within the header and each record there may be one or more fields,
separated by commas. Each line should contain the same number of fields
throughout the file. The last field in the record may not be followed by
a comma. For example:"
Yakov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/ietf-types/attachments/20050331/73e44478/attachment.html
More information about the Ietf-types
mailing list