[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply to: [list | sender only]
Re: [ddlm-group] DDLm aliases (subject changed). .. .. .. .. .
- To: Group finalising DDLm and associated dictionaries <[email protected]>
- Subject: Re: [ddlm-group] DDLm aliases (subject changed). .. .. .. .. .
- From: David Brown <[email protected]>
- Date: Mon, 31 Jan 2011 12:06:41 -0500
- In-Reply-To: <a06240800c967b204830b@[192.168.2.102]>
- References: <[email protected]> <8F77913624F7524AACD2A92EAF3BFA54166D7D1EDE@SJMEMXMBS11.stjude.sjcrh.local > <[email protected]> <a06240802c96600c48956@[192.168.2.102]> <8F77913624F7524AACD2A92EAF3BFA54166D7D1EE1@SJMEMXMBS11.stjude.sjcrh.local > <a06240800c9668e1faa7c@[192.168.2.102]> <8F77913624F7524AACD2A92EAF3BFA54166D7D1EE8@SJMEMXMBS11.stjude.sjcrh.local > <a06240802c9674292646e@[192.168.2.102]> <8F77913624F7524AACD2A92EAF3BFA54166D7D1EEB@SJMEMXMBS11.stjude.sjcrh.local > <[email protected]> <8F77913624F7524AACD2A92EAF3BFA54166D7D1EEF@SJMEMXMBS11.stjude.sjcrh.local ><a06240800c967b204830b@[192.168.2.102]>
|
Not having done any programming for many years and not being
familiar with the current jargon, I find keeping up with the rapid-fire
discussion on
_aliases requires some effort on my part and the discussion has usually
move on before I havc a chance to comment. However, being incommunicado on weekends, I took Herbert's draft home where I could sit down without distraction and see what eactly what was proposed. The errors and ambiguities in the draft did not help me get my heasd around the proposal, but I made some progress, and here are my comments. First the general comments, then particular comments interleaved in the draft. 1. _identifier_set: What does this set identify? The _id seems to flag arbitrary groups aliases. 'alias_set' would be a better name for this category, or even just 'set'. What's in a name? It sets certain switches in the brain, and if these are misset by the dataname, it may take a lot of work to get them reset. Not conducive to instant communication. 2. Why do we need both _alias and _alias_identifier_set categories? They have indentical information (if the datanames (Syd's word) or tags (Herbert's word) are any indication). I suppose (though this is no where spelled out) that _identifier_set would have its own save frame in the dictionary and would not be an attfibute of a datanmae. If this is a correct interpretation it would provide a place whare all the alias datanames in the dictionary could be listed within a single loop). This seems redundant, but I cannot speak from programming experience. If alias_identifier_set does not appesr in its own save_ frame, how does it differ from 'alias'? 3. If my supposition in 2. is correct, we would appear to have a problem. We will now have a variety of flavours of CIF dictionaries, each expressing a particular programmer's preferences for grouping the aliases. This will make no difference to the CIFs themselves as these groupings are irrelevant once a CIF has been written, but if, for example, I am given a program written by Herbert and different program written by either of the Johns, I might need a different mmCIF dictionary for each of these two programs, dictionaries that differ only in the way the aliases are gouped. When I load my CIF it cannot give instructions on which dictionary to call up because is will have no knowledge of the idiosyncrasies of the program I have chosen to use. A possible solution would be to use the _import feature to create a virtual dictioanry at run time. Thus the _identifier_set information would be held in a local dictionary that would be imported into the authorised CIF dictioanry at run time. However, there are limitations on what can be imported. The _identifier_set category could be imported but it would be impossible to import the _identifier_set_id into the alias loop by this mechanism. Since I am not sure that I understand how Herbert intends to use this feature, I do not feel competent to suggest a way in which this problem could be handled. Having programs that used different dialects of CIF dictionaries does not seem to be in line with the traditional development of CIF, particularly for a feature that is unlikely to be much used, even if they do not affect the CIFs themselves. We should think carefully about the implications of this move. 4. My detailed comments follow the feature they comment on below:
This item is deprecated. It should be deleted. The alias and xref
iitems have never been tested and it is clear from the current DDLm
that thay are placeholders that are awaiting development. If there are
any programs that make use of the items they can only have been written
by members of this group. The current xref defintiions inadequate and
unworkable. .The is no excuse for leaving this item in if we don't need
it.
This last paragraph would be easier to undestand if all the words were
present and the sentences grammatical.. In any case it should appear
under _alias,identifierr_set, not here. If I am right in thinking
alias is an attribute and alias_identifier_set is not, how does one
join a non-attribute to an attribute?
.object_id should be the second part of the _definition.id, i.e.,
'deprecated'. This needs correcting in many places.
This item should be moved to the _dictionary_xref category. The
xref.id is sufficient link. Again, the fact that it may appear in the
draft dictionaries should not prevent it being deleted in DDLm since
the draft dictionaries are just drafts and will be chaniged once we
have sorted out how to do the aliases.
I cannot make much sense of the last sentence. Perhaps there are
missing words?
See above. 'code' is not the proper .object_id
Presumably the second line should read 'need not belong to any'. The
wording above is ambiguous.The last line should read 'identifier set id' and its default value should be given explicitly. What is nul? Possible nul values are 'nul', '0', ' ', '?', '.', etc.
I assume these are not datanames that appear in the dictionaries but a
list of COMCIFS enumerations, some of which might appear in a
non-exclusive enumeration list. What happens if someone chooses
'joeblow' as an id?
What is this identifier tag - '.definiton_id' or '.definiton_set_id'?
We also need to refined the _dictionary_xref category. '.uri; should
be added, '.format' should be better derfined or deleted. Perhaps
'.version' should also be added. Definining the dictionaries is just
as important as definiting the definition_setsDavid |
begin:vcard fn:I.David Brown n:Brown;I.David org:McMaster University;Brockhouse Institute for Materials Research adr:;;King St. W;Hamilton;Ontario;L8S 4M1;Canada email;internet:[email protected] title:Professor Emeritus tel;work:+905 525 9140 x 24710 tel;fax:+905 521 2773 version:2.1 end:vcard
_______________________________________________ ddlm-group mailing list [email protected] http://scripts.iucr.org/mailman/listinfo/ddlm-group
Reply to: [list | sender only]
- Follow-Ups:
- Re: [ddlm-group] DDLm aliases (subject changed). .. .. .. .. . (Herbert J. Bernstein)
- Re: [ddlm-group] DDLm aliases (subject changed). .. .. .. .. . (Herbert J. Bernstein)
- References:
- Re: [ddlm-group] DDLm aliases (subject changed) (James Hester)
- Re: [ddlm-group] DDLm aliases (subject changed). . (David Brown)
- Re: [ddlm-group] DDLm aliases (subject changed). . (Herbert J. Bernstein)
- Re: [ddlm-group] DDLm aliases (subject changed). .. . (Herbert J. Bernstein)
- Re: [ddlm-group] DDLm aliases (subject changed). .. .. . (Herbert J. Bernstein)
- Re: [ddlm-group] DDLm aliases (subject changed). .. .. .. . (John Westbrook)
- Re: [ddlm-group] DDLm aliases (subject changed). .. .. .. .. . (Herbert J. Bernstein)
- Prev by Date: Re: [ddlm-group] Wrapping up the elide discussion
- Next by Date: Re: [ddlm-group] DDLm aliases (subject changed). .. .. .. .. .
- Prev by thread: Re: [ddlm-group] DDLm aliases (subject changed). .. .. .. .. .. .... .. .
- Next by thread: Re: [ddlm-group] DDLm aliases (subject changed). .. .. .. .. .
- Index(es):

