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

Re: Revised CIF syntax guidelines

Dear Brian,

   I agree with much of what you have said, but I repectfully
disagree with your proposed combination of (i) and (ii) because
of what I view as the overly restrictive "only if" in the lead-in 
sentence.  I follow rules; it is the mathematician in me. I
would have serious difficulty voting for a document that said
"only if" when I would not intend to conform to that constraint as 
written.  I again suggest the simple exclusion of (i) and (ii)
(as well as 3).  On reflection I also would suggest deleting (iv), not 
becuase I believe in unnecessary complexity, but because experience shows, 
e.g. in democracy being a workable form of government, in C having beaten 
Pascal, in the fact that C++ and Java exist, indeed in the very existence 
of object-orented programming, that, much to my surprise, there are times 
when complexity proves preferable to simplicity.

   Regards,
     Herbert

==============================================
Principles guiding development of Base CIF 2.0 (proposed rev 8 Apr 11)
----------------------------------------------------------------------

Preamble

CIF is a framework for exchanging and archiving scientific data,
featuring a human-readable, machine-parseable, file format designed to
serve as an exchange and archive medium.  'Base' CIF comprises the
definitions and constraints that underlie CIF and apply to all CIF
files; those aspects defining the CIF file format are documented in
the CIF Syntax specification and the CIF Common Semantic Features
specification.

Base CIF aims to remain as simple as possible by delegating
considerations such as ontology, vocabulary, data relationships, and
complex and rich data types to domain dictionaries and the DDL
formalisms by which those dictionaries are defined.  In the following,
the phrase 'domain level' refers to such documents (though it is
anticipated that only dictionaries, not DDLs, will be
domain-specific).  Definitions and constraints at domain level apply
to a particular CIF file only as declared by that file or as required
by a particular CIF processor in a particular context.

Principles

The design of base CIF 2.0 is guided by these principles:

1. A feature should be added to or changed in base CIF only if all of
the following are satisfied:

  (i) (deleted)
  (ii) (deleted)
  (iii) reliable transfer and archiving of data is not compromised
  (iv) (deleted)
  (v) it has been shown possible to implement the change at a cost
commensurate with its benefits, as demonstrated in part by a rough
consensus and running code.
  (vi) Where possible, any new CIF syntax features should be developed
as an extension to the current standard, and thus not change the
interpretation of archival files that conform with previous versions
of the CIF standard.
  (vii) Where it is impractical to provide for full backward compatibility 
as described in (vi), the relevant archival repositories and software 
developers should be consulted to arrive at a solution that will minimize 
the impact of such changes.


2. As long as the requirements in (1) are satisfied, base CIF should:
  (i) behave in a way that is consistent with common usage
  (ii) align with pre-existing standards where those standards provide
the required behaviour. CIF 1.1 can be considered a pre-existing
standard for CIF 2.0 in this context.

3. (deleted)

4. Draft changes to base CIF will be made available on the IUCr
website for public comment for a period of at least 6 weeks, following
which COMCIFS voting members, after consideration of any objections
raised, can vote to accept the change. A change will be accepted if
3/4 of COMCIFS voting members approve it.
===============




=====================================================
  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, 8 Apr 2011, Brian McMahon wrote:

> Hi James
>
> I'm sorry for the delay in responding: too many distractions, but also
> the need to mull over this rather carefully.
>
>> It is not my intention to create an absolute code,
>
> I take that for granted, but I still make the point that a written
> code can attract argument directed to the wording rather than the
> underlying spirit. Both approaches are workable - in my analogy of a
> political constitution, both "British" and "American" models lead to
> workable societies; both achieve ready consensus on obvious points of
> principle or law; both struggle with what we might call "edge cases";
> and neither judicial precedent not constitutional amendment is
> guaranteed to achieve the "right" result in such edge cases. Of
> course, if resident in Britain I abide by the unwritten constitution,
> if in America I live according to the documents of the Founding
> Fathers.
>
> It seems that COMCIFS is broadly in favour of adopting a formal set
> of principles (based on the assumption that silence yields consent),
> and I don't wish to lobby against that - simply to point out it's not
> the approach I would personally prefer.
>
>>                                                    rather to create a
>> framework for discussions and promote a certain prejudice in favour of
>> the positions outlined in the guidelines. COMCIFS voting members
>> still remain the final arbiters.
>
> That's fine, and I don't take the word "prejudice" in any pejorative
> sense (which it usually does have). If you use the rather similar word
> "bias", though, you also become aware of the importance that
> "weighting" will have - i.e. the amount of bias controlled by the
> other assumptions, aspirations, intentions and downright
> misunderstandings that people bring along as part of their individual
> baggage.
>
>> Moving on to the particular comments about points 1(i) and (ii), note
>> that the phrase "domain level" is defined in the preamble to include
>> DDL dictionaries.  Insofar as a particular DDL can be used across all
>> domains, changes that do not satisfy all of the criteria in 1, but do
>> satisfy 1(ii), would logically be implemented using DDL mechanisms (ie
>> at the "domain level").  So, for example, while fancy syntax could be
>> introduced to indicate more detail about the relationships among data
>> items in a data file, which would certainly be broadly useful, this
>> has been done at a DDL level instead. Does this adequately answer this
>> aspect of your concerns, Brian?
>
> No. Maybe this is a mis-reading, or a variant reading that others do
> not agree with; but as I read the proposed draft, the decision that we
> have made to extend the base CIF character set to Unicode would
> contravene principle 1(i), because the desired behaviour *could* have
> been achieved at a domain level, either by adoption of a suitable
> \unnn ASCII encoding agreed at DDL or dictionary level; or possibly by
> admitting UTF-8 and other multibyte encodings. [It's not clear to me
> that the principles as couched prohibit such extensions at the domain
> level.]
>
> I do understand your concerns about a formulation that is 'permissive'
> - by which I mean one that does not prohibit a certain course of action
> for which there is an appropriate rationale - because it then becomes
> difficult to stand in the way of other actions that do not have so
> strong a rationale (hence the "permissive society").
>
> Again, I am wholly in sympathy with your intention to "shelter the
> syntax from unnecessary complexity" as you go on to exemplify in your
> post. This is a restatement of Ockham's razor, which temperamentally
> I would be happy to adopt as a single concise statement of what we're
> trying to say. But it's still not an answer - what is "necessary" has
> to be teased out in the most difficult of cases.
>
> This is a matter of judgement - of fine judgement, at that. How I
> would propose to move this forward without expending even more time on
> it is as follows. I move that we vote on my proposal to amalgamate
> items 1(i) and 1(ii) as a single item:
>
>    (i) Implementation of the desired behavior by changes at the domain
>   level is not feasible, or else such changes, while feasible,  would
>   significantly reduce human readability; OR the change provides
>   significant new functionality that is widely applicable to those
>   scientific domains where CIF is used
>
> (Same text I posted last time.) If you don't get a seconder within a
> couple of days, say by Monday, we can drop the matter; I shall take
> this as a sign that COMCIFS collectively judges your position to give
> the more robust set of working principles. If there is a seconder, and
> the motion is voted against, I would take that decision in the same way.
>
> In either case, if a vote is then called on your original formulation,
> I am likely to vote for it, inasmuch as an agreed statement will still
> provide a useful referent against which to test future decisions.
>
> Best wishes
> Brian
> _______________________________________________
> comcifs mailing list
> comcifs@iucr.org
> http://scripts.iucr.org/mailman/listinfo/comcifs
>
_______________________________________________
comcifs mailing list
comcifs@iucr.org
http://scripts.iucr.org/mailman/listinfo/comcifs

Reply to: [list | sender only]