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