[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ddlm-group] Relationship of CIF2 to legacy platforms

Ok, I'll change my vote to 2048, so now three of us have said the same 
thing -- 2048, and I'll adopt Brian's interpretation -- 2048 bytes.
Any more to put this one to bed?

=====================================================
  Herbert J. Bernstein, Professor of Computer Science
    Dowling College, Kramer Science Center, KSC 121
         Idle Hour Blvd, Oakdale, NY, 11769

                  +1-631-244-3035
                  yaya@dowling.edu
=====================================================

On Fri, 20 Nov 2009, Nick Spadaccini wrote:

> Just as James changes his vote to 2048 :) I suggest we leave it at 2048
> bytes, because
>
> (a) it's long enough
> (b) we will have at least one thing we WON'T change from the CIF1
> specification.
>
> Nick
>
> On 19/11/09 11:19 PM, "Herbert J. Bernstein" <yaya@bernstein-plus-sons.com>
> wrote:
>
>> Just to simply the menu of choice, I'll change my vote to 4096.  --
>> Herbert
>>
>> =====================================================
>>   Herbert J. Bernstein, Professor of Computer Science
>>     Dowling College, Kramer Science Center, KSC 121
>>          Idle Hour Blvd, Oakdale, NY, 11769
>>
>>                   +1-631-244-3035
>>                   yaya@dowling.edu
>> =====================================================
>>
>> On Thu, 19 Nov 2009, David Brown wrote:
>>
>>> I have no strong views on line length, but the arrguments for keeping them
>>> seem a little stronger than those for abolishing them.  I have no views at
>>> all on how long the lines should be other than to note that Acta Cryst.
>>> programs get upset if there are more than 80 characters in a line.
>>>
>>> David
>>>
>>>
>>>
>>> James Hester wrote:
>>>
>>> We should resolve the Fortran line length issue as I think we've got
>>> enough information on the table - could those who haven't indicated
>>> their preference please vote either
>>>
>>> (1) CIF2 should have a maximum line length specified or
>>> (2) no line length should be specified.
>>>
>>> For bonus points, you can indicate what this length should be.
>>>
>>> So (including Nick's recent email) I count the votes as:
>>>
>>> (1) Herbert (>=2048), Nick (2048), James (4096)
>>> (2) Joe
>>>
>>> I've added my vote to the fixed line length simply because I accept
>>> Herbert's argument that legacy Fortran programs are actually important
>>> in the crystallographic world, and a restriction on line length does
>>> not impose a burden on CIF readers.  It also imposes a bit of
>>> discipline on CIF writers and helps to produce a readable file.
>>>
>>> On Fri, Nov 13, 2009 at 3:47 AM, Joe Krahn <krahn@niehs.nih.gov> wrote:
>>>
>>> Nick Spadaccini wrote:
>>>
>>> On 3/11/09 12:53 AM, "Joe Krahn" <krahn@niehs.nih.gov> wrote:
>>>
>>> Herbert,
>>> I am only suggesting that maintained Fortran code ought to be able to
>>> utilize F2003 STREAM I/O, supported by current versions of GFortran,
>>> Intel Fortran and Sun Fortran.
>>>
>>> Of course, I probably am not considering all of the issues. STREAM I/O
>>> avoids the need for a fixed maximum record length, but even the newest
>>> Fortran compilers have very limited UTF-8 support. Even with STREAM I/O,
>>> it is not trivial to count trailing blanks as significant.
>>>
>>> Maybe the biggest problem is UTF-8. IMHO, it makes sense for UTF-8 to be
>>> an optional encoding, rather than just declaring CIF2 is all UTF-8. This
>>>
>>> Not sure what you gain by doing this. If it is pure ASCII only then the
>>> declaration of UTF-8 inhibits nothing, since ASCII is a subset. If it is not
>>> pure ASCII, then it needs to be UTF-8. I can't see how knowing in advance
>>> that it is a subset of UTF-8 or possibly the full set of UTF-8 gives you
>>> anything.
>>>
>>> cheers
>>>
>>> Nick
>>>
>>> A compiler/language not aware of UTF-8 could avoid errors by rejecting
>>> CIF files that contain UTF-8. However, I think the approach being taken
>>> is just to allow implementations to restrict usage, rather than put it
>>> in the specifications. For example, the plan seems to be that
>>> DDL/dictionary definitions will be used to avoid UTF-8 in data names,
>>> where it is most likely to be a problem. So, you are right: there is no
>>> reason for the CIF2 syntax to make UTF-8 optional when the dictionaries
>>> can restrict characters to the ASCII subset.
>>>
>>> The other potential legacy issues I know of are fixed maximum line
>>> lengths, and significant trailing blanks. Dictionary definitions cannot
>>> avoid these. It might be possible to take a similar approach, by
>>> avoiding them by implementation conventions rather than making it part
>>> of the spec. If these are only going to be an issue for a few more
>>> years, it would avoid having to make another syntax change in the near
>>> future.
>>>
>>> My main interest here is to avoid incompatible implementations. I also
>>> think that Fortran, and any other line-oriented I/O software, should be
>>> able to do stream-oriented I/O in the near future.
>>>
>>> Joe
>>>
>>> _______________________________________________
>>> ddlm-group mailing list
>>> ddlm-group@iucr.org
>>> http://scripts.iucr.org/mailman/listinfo/ddlm-group
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>> _______________________________________________
>> ddlm-group mailing list
>> ddlm-group@iucr.org
>> http://scripts.iucr.org/mailman/listinfo/ddlm-group
>
> cheers
>
> Nick
>
> --------------------------------
> Associate Professor N. Spadaccini, PhD
> School of Computer Science & Software Engineering
>
> The University of Western Australia    t: +61 (0)8 6488 3452
> 35 Stirling Highway                    f: +61 (0)8 6488 1089
> CRAWLEY, Perth,  WA  6009 AUSTRALIA   w3: www.csse.uwa.edu.au/~nick
> MBDP  M002
>
> CRICOS Provider Code: 00126G
>
> e: Nick.Spadaccini@uwa.edu.au
>
>
>
>
> _______________________________________________
> ddlm-group mailing list
> ddlm-group@iucr.org
> http://scripts.iucr.org/mailman/listinfo/ddlm-group
>
_______________________________________________
ddlm-group mailing list
ddlm-group@iucr.org
http://scripts.iucr.org/mailman/listinfo/ddlm-group

Reply to: [list | sender only]