Re: Format Tests

David,

from some of your recent posts I have been wondering whether you are 
causing unnecessary obstacles, but then again I'm not sure. Let me say 
that if you don't like the idea of cooperation, just say a word and I'm 
backing off. - I regard my contributions here as offers to the benefit 
of the PWS file format. I'm not doing this to please the PWS project or 
its people but for the sake of a community, whether big or small, who 
might be using this file format under various applications and possibly 
various purposes. - It is my believe that all users and all PWS 
applications will benefit from an open and effective file format 
regulation, providing the means for as little loss/friction as possible 
when files are cross-used among several PWS applications or various 
historical software versions.

It is my believe, hence, that the format definition should be a) as 
simple as possible, b) as tolerant as possible. In this light I'ld 
comment on some of your recent points:

i)  (Simplicity I) no sequence prescriptions in any field arrays! The 
format definition should make it explicit that both header field list 
and record field list must be fully apprehended in random type sequence 
of its fields. Any ordering prescriptions might cause problems in 
applications and is a superfluous source of errors. There is no 
algorithmic necessity for any ordering (with the exception of the list 
terminating field 0xff).

ii)  (Simplicity II) no complex field structures where possible; so I 
support suggestion to create 2 fields for "Last operator" and "Last host 
(computer)"

iii) (Tolerance I) the most simple and effective rule here is that a PWS 
application should preserve unknown fields when saving a file, 
regardless of their place and value, i.e. no two-class support depending 
on type ranges or the record/header distiction. Anything else I regard 
as over-protective (protect what exactly?) and again forseeably - but 
hopefully not deliberately - causing problems.

iv)  (Tolerance II) as a compensation for openness there must exist a  
regulation to devide usage of field types. The simple 0x7f boundary does 
the job as already described and secures a wide range of fields for the 
world of PWS only. I personally have seen a second boundary at 0x3f; 
above it and below 0x7f could be a range for "approved PWS applications" 
(well, I don't like the word "clones" any more because mutual feature 
copy is already in full swing). Specific type values would be given out 
to these application once they need them. This has the advantage that 
these approved applications share a protected zone and could refer to 
the "rest of the world" as "using above 0x7f types". I walk from the 
assumption here that 64 field types will provide for many more decades 
of development of the (native) PWS program. - (The second boundary is an 
add-on and the system also works without it.)

That's how I've seen it,
- Wolfgang

dk wrote:
> Wolfgang,
>
> I have replied to your Support Request as I had some difficulties with the
> time fields in the records and header.
>
> However, on further tracing, I see that the order in which you write the
> header records seems to be in the inverse of their type value.  There is
> nothing in the "FormatVn.txt" file to say this is wrong.  However, I would
> like the format changed to mandate that the version number (record type
> 0x00) is *always* the first field in the header.
>
> Regards,
>
> David
>
>
>
>   

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/