[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply to: [list | sender only]
Re: [ddlm-group] The Grazulis eliding proposal: how to incorporateinto CIF?. .
- To: ddlm-group <firstname.lastname@example.org>
- Subject: Re: [ddlm-group] The Grazulis eliding proposal: how to incorporateinto CIF?. .
- From: "Bollinger, John C" <John.Bollinger@STJUDE.ORG>
- Date: Tue, 28 Jun 2011 08:46:53 -0500
- Accept-Language: en-US
- acceptlanguage: en-US
- In-Reply-To: <BANLkTi=KKXU7HCc7r2Xji0ssaJg+xkw9Jw@mail.gmail.com>
- References: <BANLkTi=KKXU7HCc7r2Xji0ssaJg+xkw9Jw@mail.gmail.com>
On Tuesday, June 28, 2011 2:23 AM, James Hester wrote: >As none of you have raised any substantial objections to the Grazulis eliding proposal, I think we can consider it accepted. The question now arises as to how it will fit into the CIF framework. I see the following possibilities: > >(1) As a required protocol for all CIF semicolon-delimited text strings (must be recognised by CIF readers) >(2) As an available protocol for all CIF semicolon-delimited text strings (may not be recognised by all CIF readers) >(3) As a string type defined in DDLm for use in domain dictionary definitions (only needs to be recognised by domain-specific software) > >My comments: >Option (3) has the formal effect of requiring that either the type of string delimiter is carried forward to the dictionary layer, so that >triple-quote delimited strings are not inadvertently "decoded", or else that the protocol is applied uniformly across all multi-line string >constructs for that particular dictionary type. > >Option (2) insofar as it involves optional behaviour essentially sidelines the proposal, as CIF writers cannot count on it being understood at >the reading end and so cannot use it to encode important information > >Option (1) imposes extra burdens on CIF parser writers, although as Saulius notes it is not particularly difficult to implement. > >My preference is either (1) or (3), perhaps inclining towards (3) in order to shift complexity to the dictionary level. If the protocol is seen to be generally useful, it would be reasonable to prefer (1). I disfavor option 2. Accepting the proposal under those terms would be near meaningless. I agree that option 3 would require that string delimiter type be available to the dictionary layer, or at least that it be a per-dictionary option uniformly applicable to all text blocks. But that's only symptomatic of the true problem: adding the feature on those terms blurs the boundary between CIF's syntax and its semantics. I don't want to go there, but we could perhaps define the option as a DDLm string type without regard to the string delimiters used. If we require a newline in the string as part of the protocol signature then the only CIF 1.1 string type affected would be text blocks. At that point, however, I prefer option 1. I would like to see the proposal accepted. Although I prefer option 1, I would be OK with the variant of option 3 described above. HOWEVER, whichever option might be chosen, I should like to see the line-folding protocol adopted and given the same status. Only together do those provide the ability to include truly arbitrary text. John -- T +61 (02) 9717 9907 F +61 (02) 9717 3145 M +61 (04) 0249 4148 Email Disclaimer: www.stjude.org/emaildisclaimer _______________________________________________ ddlm-group mailing list email@example.com http://scripts.iucr.org/mailman/listinfo/ddlm-group
Reply to: [list | sender only]
- Re: [ddlm-group] The Grazulis eliding proposal: how to incorporateinto CIF?. . (Herbert J. Bernstein)
- Prev by Date: Re: [ddlm-group] The Grazulis eliding proposal: how to incorporateinto CIF?
- Next by Date: Re: [ddlm-group] The Grazulis eliding proposal: how to incorporateinto CIF?
- Prev by thread: Re: [ddlm-group] The Grazulis eliding proposal: how to incorporateinto CIF?
- Next by thread: Re: [ddlm-group] The Grazulis eliding proposal: how to incorporateinto CIF?. .