>>those requesting that this be done. Those who have full time programmers
>>or those that sell products for data analysis are needed to help users,
>>not to dictate what they  need.
>>Jim Houston

>As one of Jim Houston's "backyard" flow people (I actually do have a
>FACStar plus in my backyard- see advert in another message) who dabbles
>with programming, I would like to see a little less flexibility, and more
>standardisation in the standard. I believe that integer-based data files
>are the way to go, losing the ascii and floating point options (which I
>haven't seen implemented).  I would also lose the multiple data-set file
>option, since this could be better handled by a separate database manager,
>or even by putting a group of files in a separate directory. I would
>implement a record/structure -based text section with only the mandatory
>keywords and their values (this could be made backwards-compatible by
>including the old delimiters) to overcome misinterpretation of the text
>section format by those implementing FCS software, and allowing readers to
>parse through errors (such as empty value fields) more readily; at the very
>least I'd make a standard delimiter.  It would also speed things up parsing
>wise if there were three file types, one for each data mode with file type
>flagged in the header: eg FCS3.U, FCS3.C, FCS3.L for histogram, contour,
>and list data respectively, notice that this alternative naming wouldn't
>change the string length for the file type information, and if there is
>ever a revision of FCS 3, the fifth character could be used to denote it.
>Since the data are organised so differently in each of these types, and
>they are handled so differently, I think it's reasonable that these
>differences are flagged early in the parsing.
>I would put user-specified keywords in a section separate from the (now)
>structured text section, the analysis section would be ideal.
>The advantages of the above changes are that they are compatible with the
>proposed standard, but speed up and ease parsing (and writing) of the
>information that are needed to properly analyse the file.  Using a
>structured text section removes ambiguity caused by a commentable delimiter
>(eg cytomation's empty values, BD's LYSYS allowing you type the delimiter
>into text fields).  User-specific data would be written to a different
>section (the analysis part), where it can be found by those in the know.
>To avoid Swiftian confusion over byte order it may be worthwhile explicitly
>writing an integer constant (eg 1) into the text part, this would allow
>automatic detection of byte order, since if byte swapped it would be read
>incorrectly (eg as 256), an integer based on printable character values
>might be preffered.
>Mario roederer's wish list hasn't hit the forum yet, so it looks like this
>list  may be the the easiest place for these discussions, that's why I've
>sent my message here, and it's where I'd prefer to see the discussion held.
>Ray

>(ME!ME!ME!- sorry about the egocentric nature of this letter)

>At 12:24 pm -0500 18/7/97, Jim Houston wrote:

>>I would like to see FCS3.0 left alone.  There are many users in Flow who
>>have no idea what the capablilities of the FCS standard are or what it
>>does for them.

>>I have seen the world of flow data stored differently by each vendor.

>>us not go back to that. FCS has served the flow world well.

>>Let us also not forget the backyard flow persons who dabble at programming
>>on their spare time to make FCS work for them. Who share code and ideas.

>As one of Jim Houston's "backyard" flow people (I actually do have a
>FACStar plus in my backyard- see advert in another message) who dabbles
>with programming, I would like to see a little less flexibility, and more
>standardisation in the standard. I believe that integer-based data files
>are the way to go, losing the ascii and floating point options (which I
>haven't seen implemented).  I would also lose the multiple data-set file
>option, since this could be better handled by a separate database manager,
>or even by putting a group of files in a separate directory. I would
>implement a record/structure -based text section with only the mandatory
>keywords and their values (this could be made backwards-compatible by
>including the old delimiters) to overcome misinterpretation of the text
>section format by those implementing FCS software, and allowing readers to
>parse through errors (such as empty value fields) more readily; at the very
>least I'd make a standard delimiter.  It would also speed things up parsing
>wise if there were three file types, one for each data mode with file type
>flagged in the header: eg FCS3.U, FCS3.C, FCS3.L for histogram, contour,
>and list data respectively, notice that this alternative naming wouldn't
>change the string length for the file type information, and if there is
>ever a revision of FCS 3, the fifth character could be used to denote it.
>Since the data are organised so differently in each of these types, and
>they are handled so differently, I think it's reasonable that these
>differences are flagged early in the parsing.
>I would put user-specified keywords in a section separate from the (now)
>structured text section, the analysis section would be ideal.
>The advantages of the above changes are that they are compatible with the
>proposed standard, but speed up and ease parsing (and writing) of the
>information that are needed to properly analyse the file.  Using a
>structured text section removes ambiguity caused by a commentable delimiter

>(eg cytomation's empty values, BD's LYSYS allowing you type the delimiter
>into text fields).  User-specific data would be written to a different
>section (the analysis part), where it can be found by those in the know.
>To avoid Swiftian confusion over byte order it may be worthwhile explicitly
>writing an integer constant (eg 1) into the text part, this would allow
>automatic detection of byte order, since if byte swapped it would be read
>incorrectly (eg as 256), an integer based on printable character values
>might be preffered.

>Mario roederer's wish list hasn't hit the forum yet, so it looks like this
>list  may be the the easiest place for these discussions, that's why I've
>sent my message here, and it's where I'd prefer to see the discussion held.
>Ray

>(ME!ME!ME!- sorry about the egocentric nature of this letter)

>At 12:24 pm -0500 18/7/97, Jim Houston wrote:
>>I would like to see FCS3.0 left alone.  There are many users in Flow who
>>have no idea what the capablilities of the FCS standard are or what it
>>does for them.
>>I have seen the world of flow data stored differently by each vendor.  Let
>>us not go back to that. FCS has served the flow world well.
>>Let us also not forget the backyard flow persons who dabble at programming
>>on their spare time to make FCS work for them. Who share code and ideas.
>>Reformating FCS to meet specific clincal needs is a bit self centered for
>>those requesting that this be done. Those who have full time programmers
>>or those that sell products for data analysis are needed to help users,
>>not to dictate what they  need.
>>Jim Houston
>                              Ray Hicks
>________________________________________________________________________
>|University of Cambridge          |Tel              01223 330149        |
>|Department of Medicine           |Fax             01223 336846         |
>|Level 5, Addenbrookes Hospital   |e-mail         <rh...@cus.cam.ac.uk> |
>|Hills Road Cambridge             |Web  http://facsmac.med.cam.ac.uk    |
>|CB2                              |ftp server  ftp://131.111.80.78      |
>|UK                               |                                     |
>|_________________________________|_____________________________________|

>                              Ray Hicks
>________________________________________________________________________
>|University of Cambridge          |Tel              01223 330149        |
>|Department of Medicine           |Fax             01223 336846         |
>|Level 5, Addenbrookes Hospital   |e-mail         <rh...@cus.cam.ac.uk> |
>|Hills Road Cambridge             |Web  http://facsmac.med.cam.ac.uk    |
>|CB2                              |ftp server  ftp://131.111.80.78      |
>|UK                               |                                     |
>|_________________________________|_____________________________________|