[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply to: [list | sender only]
Re: [ddlm-group] New syntax: 'marker' characters
- To: Group finalising DDLm and associated dictionaries <ddlm-group@iucr.org>
- Subject: Re: [ddlm-group] New syntax: 'marker' characters
- From: Joe Krahn <krahn@niehs.nih.gov>
- Date: Wed, 04 Nov 2009 14:11:57 -0500
- In-Reply-To: <279aad2a0911031947i5db5af37xef4d497b1ec72c09@mail.gmail.com>
- References: <279aad2a0910281823tafd2e31o46e93a68e03a4c89@mail.gmail.com> <4AE9BA8F.8090405@mcmaster.ca> <20091029130659.X67614@epsilon.pair.com><279aad2a0911031947i5db5af37xef4d497b1ec72c09@mail.gmail.com>
The advantage of DDL ordering hints is that it is much more flexible. A simple approach of beginning+middle+end may solve some problems, but someone will eventually find a situation where more control is needed. In addition, preferred ordering could formalize what many CIF programs already do by "pretty" printing. If you just follow CIF rules, there is no reason for x,y,z coordinates to be in order or even adjacent. From a pure database view, that does not matter, but most people prefer human-readable files. With CIF-2 supporting bracket-delimited lists, one could define a DDL syntax to allow ordering for either individual items, or by groups. For example, to give an explicit order, use: [ item1 item2 item3 item4 item5 ... ] Or, for grouping with the begin+middle+end method, use: [ [ begin1 begin2 ... ] [ middle1 middle2 ... ] [ end1 end2 ... ] ] I would also add numeric formatting hints such as how many digits of precision for coordinates or matrices. I don't think the DDL has any formatting rules yet, even though they are generally required for practical use of CIF without rounding errors or excessive precision. Joe Krahn James Hester wrote: > Hi Herbert and colleagues: Herbert has proposed a finer-grained > solution to part of the original problem. One part of the problem I > was addressing was that very large CIF files are not necessarily laid > out in a manner that allows for efficient selective processing. > Herbert's proposal doesn't completely solve this problem, in that one > still needs to parse all preceding parts of the file in order to get > to a particular section. Herbert's solution does give a performance > boost to those programs that need something from the earlier part of a > datablock, in those cases where someone has adopted the recommended > ordering. > > Quite apart from the markers proposal, I think it would be worth > exploring Herbert's proposal further, although I don't understand the > reasons one would need such a fine-grained ordering. > > On Fri, Oct 30, 2009 at 4:29 AM, Herbert J. Bernstein > <yaya@bernstein-plus-sons.com> wrote: >> The idea of markers creates interesting possibilities and problems with >> respect to ordering. Isn't the real issue one of relative ordering of >> presentation of categories, rather than beginning, middle and end? >> We could just as easily have a need to organize the middle in more detail. >> The same issues may also arise within a category. > >> How about adding an arbitrary string as an attribute for any item or >> category giving its suggested sort order, where the sorting would be >> done lexicographically among the strings, with no specified ordering >> among items with the same value. Note that a blank string comes before >> all other strings. >> >> If nothing were specified the intention would be to assume the ordering >> string ".", so that strings beginnng with blank would sort ahead of >> all items with no specified ordering and strings beginning with any >> letter of the alphabet would sort after the unspecified orderings. >> This would give the effect of beginning, middle and end, but allow >> arbitrary insertions into the order. >> >> Thus " beginning" would come before the unspecified orderings and >> "zzz_end" would come after all of the unspecified orderings. >> >> There may be other presentation issue, so I would suggest starting >> a PRESENTATION category with the tag >> >> _presentation.suggested_ordering >> >> the value of which would be a Text (if we want to allow the maximal >> flexibility) or Code (for simplicity). >> >> Note that this would be a suggested ordering, not mandatory. > _______________________________________________ ddlm-group mailing list ddlm-group@iucr.org http://scripts.iucr.org/mailman/listinfo/ddlm-group
Reply to: [list | sender only]
- References:
- [ddlm-group] New syntax: 'marker' characters (James Hester)
- Re: [ddlm-group] New syntax: 'marker' characters (David Brown)
- Re: [ddlm-group] New syntax: 'marker' characters (Herbert J. Bernstein)
- Re: [ddlm-group] New syntax: 'marker' characters (James Hester)
- Prev by Date: Re: [ddlm-group] New syntax: 'marker' characters
- Next by Date: Re: [ddlm-group] New syntax: 'marker' characters
- Prev by thread: Re: [ddlm-group] New syntax: 'marker' characters
- Next by thread: [ddlm-group] CIF header
- Index(es):