Re: Re[2]: Leave FCS3.0 alone.

Ray Hicks (rh208@cus.cam.ac.uk)
Mon, 28 Jul 1997 15:35:28 +0100

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 <rh208@cus.cam.ac.uk> |
|Hills Road Cambridge |Web http://facsmac.med.cam.ac.uk |
|CB2 |ftp server ftp://131.111.80.78 |
|UK | |
|_________________________________|_____________________________________|