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

Re: [ddlm-group] DDLm aliases (subject changed)

Dear John,

   These are tag groups, rather than category groups, but I can
see that using the word group could be confusing.  We have been
through "style", "virtual dictionary" and "group", how about one
of the following:


I don't care much about the name, but I really need the


At 11:00 AM -0500 1/23/11, John Westbrook wrote:
>Hi Herbert,
>Category groups are an organizational tool for dictionaries in DDL2.
>We usually describe this as a chaptering mechanism but it also provides
>a mechanism to construct a hierarchy of category relationships which is
>not tied to the underlying parent-child/foreign key relationships.
>Group membership as well as subcategory membership are explicitly
>supported as part of the DDL. This is used as a means to select
>sets of extensions, categories for particular experimental methods,
>content areas within methods, and the like.    I would prefer it
>to remain this way rather than turn this into parsing directives with
>comments.  Perhaps I misunderstand your suggestion with the '###'
>On 1/23/11 8:18 AM, Herbert J. Bernstein wrote:
>>  Dear James,
>>  In my case the dictionaries to be specified with the grouping tag to
>>  validate an imgCIF file against DDL2 would be a new DDLm imgCIF
>>  dictionary plus either a new DDLm mmCIF dictionary, whenever that is
>>  ready, or the existing DDL2 mmCIF dictionary.
>>  To validate against DDLm, the best choice would, of course, be a new
>>  DDLm imgCIF dictionary plus a new DDLm mmCIF dictionary. I am not
>>  certain if using an existing DDL2 mmCIF dictionary will or will not work
>>  in that case. It depends on what changes John W. has in mind in the move
>>  of mmCIF to DDLm.
>>  For a more self-contained dictionary, such as, say the core, I am not
>>  certain if it will need to specify any dictionaries other than itself,
>>  but that, of course depends on how many pieces it is broken up into.
>>  As for rules for a grouping, as I said, I seem to be seeing most of the
>>  basic rules for category management from DDL2 in DDLm. The differences
>>  seem to be small, mainly a matter of DDLm being a bit more fussy about
>>  things such as unrolling a catgeory or not. The lexical scan issues we
>>  have introduced are not themselves in the dictionary. Inasmuch as the
>>  category management issue difference seem small and the lexical
>>  differences have to be handled by parameters in the lexer, to start, I
>>  will handle it with flags in the code, as I have done in the past for
>>  DDL1 versus DDL2 differences in CIFtbx and CBFlib.
>>  What happens after that depends on how well it works and, what, if
>>  anything, people feel needs to be adjusted in the DDL to handle such
>>  differences better than by flags in the code.
>>  As for the archived versus current distinction -- I have to deal
>>  with continuing additions to and changes in imgCIF, so the
>>  imgCIF dictionary will continue to evolve, and I would much
>>  rather maintain one base the reference dictionary in DDLm than
>  > having to maintain 2 parallel dictionaries now (DDLm and DDL2)
>>  and 3 parallel dictionaries shortly (DDLm, DDL2 and DDL1).
>>  To use existing software that is out in the hands of users,
>>  I will have to provide updated DDL2 dictionaries, but with
>>  the grouping tags, I expect to be able to use a slightly augmented
>>  DDLm dictionary as a base for automatically an generated DDL2
>>  dictionary -- and that is actually the first use I will be
>>  making of the grouping tags.
>>  I doubt if users will want to modify existing data files to
>>  specify both a dictionary and a group. Indeed I doubt they
>>  will take the effort to even specify the dictionary, but
>>  it cannot hurt to encourage them to do so. For those who
>  > decline, I will handle it with program parameters. For
>>  those who are willing, I would suggest we add a place for
>>  grouping in the initial comments. Right now we put the
>>  CBF dictionary version in the initial "magic number" comment:
>>  ###CBF: VERSION 1.6
>>  we could add the grouping(s) there as in
>>  or
>>  It does not make much sense to specify this in terms if a
>>  group other than DDL2 or DDL1 because that is precisely the
>>  distinction we are trying to convey, but, yes, for test
>>  versions we can use
>>  or somesuch to avoid confusion with something that is
>>  not yet official. Ultimately, the DDL1/DDL2/DDLm groupings
>>  are liekly to be the most intutively clear and useful ones.
>>  Now we just need to settle the issue of do we or do we not
>>  put this in with the alias items or do we put it by itself,
>>  and I can get started on setting up a DDLm imgCIF dictionary
>>  for DDL2 and DDL1 dictionary generation.
>>  So -- how do other people feel about conflating the grouping with
>>  the xfer code? I can live with it either way.
>>  Regards,
>>  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 Sun, 23 Jan 2011, James Hester wrote:
>>>  Hi Herbert: I think we are agreed that the 'grouping' attribute is
>>>  useful, but disagree on how to use it, so there is probably enough
>>>  agreement within this group to move forward with an addition to DDLm
>>>  and defer discussion on exactly what enumerated values it can take. I
>>>  would obviously prefer that this grouping tag not take values of
>>>  DDL2/DDL1/DDLm until you have shown that these groupings are
>>>  meaningful, probably through a demonstration. Incidentally, are you
>>>  (Herbert) happy with the concept that a CIF datafile would specify
>>>  both a dictionary and a 'group', which would be the basis for software
>>>  to run validation checks?
>>>  What DDL2 rules would you validate using a DDLm dictionary and DDL2
>>>  grouping tag? This seems to be where we disagree.
>>>  Yes, DDLm dictionaries can validate all *archived* files with respect
>>>  to the *DDLm* data model, and those archived files can thereby take
>>>  advantage of new DDLm features. There seems little to no point,
>>>  however, using a DDLm file to validate an archived file against a
>>>  pseudo-DDL2 dictionary derived from a DDLm dictionary (even if it were
>>>  possible), because if you wanted to validate against DDL2 you would
>>>  just use current tools and the DDL2 dictionary the archived file was
>>>  originally generated with respect to. If you plan to generate new
>>>  (not archived) data files that use datanames derived from a DDL2
>>>  perspective of a DDLm dictionary instead of just the DDLm dictionary,
>>>  one has to ask, why? You can generate perfectly legitimate CIF1
>>>  syntax datafiles that validate against a DDLm dictionary, if syntax is
>>>  the concern.
>>>  In any case, I won't argue against the DDL1/2/m grouping tag if you
>>>  can come up with a nice demonstration.
>>>  On Sun, Jan 23, 2011 at 1:39 PM, Herbert J. Bernstein
>>>  <yaya@bernstein-plus-sons.com> wrote:
>  >>> Dear Colleagues,
>>>>    I can find almost nothing in James side comments about DDLm versus
>>>>  DDL2 versus DDL1 with which I agree.  I really do believe that
>>>>  I will be able to write a single DDLm dictionary and supporting
>>>>  software that will be able to validate current imgCIF files against
>>>>  DDL2 rules, a CIF2 imgCIF file against DDLm rules, and, hopefully
>>>>  a new DDL1 imgCIF file against DDL1 rules.  Thus far I have not
>>>>  found anything in DDLm that will prevent a DDLm dictionary with
>>>>  a few added tags (such as something of the sort David and I have
>>>>  proposed) from carrying all the information needed for this purpose,
>>>>  but I am more familiar with DDL2 than with DDL1.  Perhaps James
>  >>> is referring to some inherent conflict between DDLm and DDL1,
>>>>  but I really thought the intent of DDLm was to allow it to become
>>>>  the dictionary definition language for dictionaries that could
>>>>  be used to validate _all_ archived DDL1 and DDL2 data files.
>>>>    Certainly, in using that dictionary for DDL2 validation, I will
>>>>  be using it in a way that is not consistent with all DDLm rules, e.g.
>>>>  by not honoring the list restriction-- but that is precisely the point.
>>>>  Most of what is in DDLm looks very similar to what is already in
>>>>  DDL2, so that specialization look to me to very doable, and DDLm
>>>>  seems to have support of the major concepts, such as the list flag
>>>>  from DDL1.
>>>>    So right now, I have no idea what misconception James is referring to,
>>>>  but does it really matter?  I will either succeed, or I will fail,
>>>>  but the additions I have asked for will not do any harm to those
>>>>  who do not use them.
>>>>    I can cope either with David's and John's approach of
>>>>  putting the grouping information in with the alias information,
>>>>  or with James wish to go back to my original proposal to
>>>>  have the group information separated out.  I just need a
>>>>  way to organize the grouping relationship among stylistically
>>>>  different tags with the same meanings.   If you all prefer,
>>>>  I can just work up  an imgCIF DDLm dictionary using
>>>>  a modified DDLm with a few added tags using the prefix mechanism.
>>>>  That might help in understanding the issues I am looking at
>>>>  without trespassing on what is or is not formally part of DDLm.
>>>>  For the moment I would put the mapping information into
>>>>  a separate category, but make it joinable to alias, so it
>>>>  can be used either the way John B. has proposed or separately
>>>>  as James has proposed.  The only point that seems to be a
>>>>  real sticking point is whether the grouping identifier should
>>>>  be conflated with the xref code or not.  James seem to feel
>>>>  very strongly that it should be distinct.  John B. argued very
>>>>  strongly that the grouping identifier had to be conflated with
>>>>  the xref code.  I think it is clearer to make it distinct, but
>>>>  that, other than being a little confusing, John B.'s approach
>>>>  does no real harm.
>>>>    What do other people think about conflating the grouping
>>>>  identifier with the xref code?  I'll go along with whatever
>>>>  the majority chooses on that issue.
>>>>    Regards,
>>>>      Herbert
>>>>  At 12:19 PM +1100 1/23/11, James Hester wrote:
>>>>>  I believe this discussion arose out of a misconception, but will end
>>>>>  up producing something useful.  First of all, we should be clear that
>>>>>  the only well-defined meaning of "DDL1/DDL2/DDLm tag" is "a dataname
>>>>>  defined in a dictionary written using DDL1/DDL2/DDLm".  Note in
>>>>>  particular that all DDL1 and DDL2 tags are consistent with CIF1
>>>>>  syntax, and writing a DDLm dictionary with CIF1-compatible tags is
>>>>>  also not troublesome.  This means that it is simple to write a DDLm
>>>>>  imgCIF or coreCIF dictionary where datanames satisfy CIF1 syntax
>>>>>  rules.  A datafile in CIF1 syntax can then refer to the DDLm
>>>>>  dictionary as the reference for the datanames.
>>>>>  On the other hand, it is not possible to write a DDLm dictionary that
>>>>>  can serve as a DDL1 or DDL2 dictionary, because the DDL languages are
>  >>>> different and incompatible.  Simply rewriting the tags does not change
>>>>>  the fact that the tag is defined in a DDLm dictionary and therefore is
>>>>>  interpretable using DDLm semantics *only*. The concept of a virtual
>>>>>  dictionary generated from a "master" DDLm dictionary but with
>>>>>  DDLm/DDL1/DDL2 flavours is therefore meaningless and should be
>>>>>  abandoned.
>>>>>  Nevertheless, an important use case for rewriting tags has been
>>>>>  identified by Herbert: transitioning from the use of tags with a local
>>>>>  identifier to those using a "global" (ie no namespace) identifier.
>>>>>  With something like the tag_style proposal in place, the DDLm
>>>>>  dictionary writer can write the dictionary as if it were a global
>  >>>> dictionary (this may particularly help with dREL methods) and include
>>>>>  a "local" tag_style which gives an alternate dataname that includes
>>>>>  the local section. In tandem with this, any datafiles containing
>>>>>  datanames defined in this local dictionary would use the audit
>>>>>  category to specify both a dictionary *and* a style.  If only "local"
>>>>>  datanames are in use, then the style would be "local"; if the
>>>>>  dictionary becomes a standard, no rewriting is necessary, and
>>>>>  datafiles can now just use the default value of style ("standard").  I
>>>>>  think this is a compelling use case, but still have to think through
>>>>>  how dictionary merging will work.
>>>>>  The second future use case is that of datanames in a DDLm dictionary
>>>>>  containing non-ASCII code points.  These, and only these, DDLm
>>>>>  datanames are not CIF1-compatible.  A style could therefore be added
>>>>>  giving the "ASCII" equivalent dataname.
>>>>>  As John W was suggesting (at least reading between the lines), the
>>>>>  above two use cases are semantically distinct from aliases.  Aliases
>>>>>  point to definitions in a dictionary and state that the aliased
>>>>>  dataname is the equivalent dataname in a different dictionary.  As the
>>>>>  dictionary DDL languages may be different, there are no explicit
>>>>>  guarantees that all semantic properties (e.g. category relationships)
>>>>>  can be preserved in making this translation.  On the other hand, the
>>>>>  tag_style use is a simple rewriting of the dataname preserving perfect
>>>>>  semantic identity.
>>>>>  Therefore, I believe that the tag_style tag should not be conflated
>>>>>  with aliases, but should be created in a separate category.  Note also
>>>>>  that "local" and "ASCII" are not mutually exclusive designations, so
>>>>>  some further work is necessary to get everything to work together
>>>>>  properly (e.g. how do I transition between "local + ASCII", "local",
>>>>>  "ASCII" and "standard+ASCII"?).  I also think that "style" is probably
>>>>>  not the best terminology to use - perhaps "presentation" or "view"
>>>>>  would be better.
>>>>>  I have so far no objection in principle to normalising out the
>>>>>  dictionary using dictionary_xref as John has proposed.
>>>>>  On Sat, Jan 22, 2011 at 7:47 AM, Herbert J. Bernstein
>>>>>  <yaya@bernstein-plus-sons.com> wrote:
>>>>>>   This can be made to work, but for my uses, there are
>>>>>>   some minor issues:
>>>>>>   1.  I will be grouping the primary DDLm tag.  With the
>>>>>>   _definition.xref_code removed, the primary DDLm tag
>>>>>>   will have to be aliased; and
>>>>>>   2.  With multiple xref codes for a given tag (e.g.
>>>>>>   DDL2 and DDLm), it would be more appropriate to
>>>>>>   normalize and put the tags and xref codes into
>>>>>>   a sub-category, rather than to keep repeating the
>>>>>>   same tag.  This would have the advantage of allowing
>>>>>>   the alias category to return to a non-compound key
>>>>>>   and would also allow all the grouping of
>>>>>>   tags in a dictionary to be gathered on a separate
>>>>>>   block, if desired.
>>>>>>   For these reasons, I suggest
>>>>>>   1.  Leave _alias.dictionary_uri, but deprecate it in
>>>>>>   favor of:
>>>>>>   2.  Create an ALIAS_XREF category with the
>>>>>>   following tags, forming a composite key
>>>>>>   _alias_group.definition_id
>>>>>>       a tag identifier belonging to a group
>  >>>>>  _alias_group.xref_code
>>>>>>       a code identifying a real or virtual dictionary
>>>>>>   or other logical groups of tags to which the tag
>>>>>>   belongs
>>>>>>   The other tags that John proposes for David's uses
>>>>>>   actually fit better in terms of normalization in this sub-
>>>>>>   category, than on the top level, but that is a decision
>>>>>>   for David to make.  I am happy either way.
>>>>>  >
>>>>>>   The addition to the ddl dictionary would be:
>>>>>>   save_ALIAS_XREF
>>>>>>     _definition.id      alias_xref
>>>>>>     _definition.scope   Category
>>>>>>     _definition.class   List
>>>>>>     _definition.update  2011-01-21
>>>>>>   ;
>>>>>>      The attributes used to specify the actual dictionary,
>  >>>>>     virtual dictionary, or other logical grouping of
>>>>>>      tags indicated by an xref code to which a given tag belong.
>>>>>>      The default xref code under which all tags for which
>>>>>>      no xref group is defined is the one specified by
>>>>>>      a null value.
>>>>>>   ;
>>>>>>      _category.parent_id  alias
>>>>>>      _category_key.primitive  ['_alias_xref.definition_id',
>>>>>>                                '_alias_xref.xref_code']
>>>>>>       save_
>>>>>>   save_alias_xref.definition_id
>>>>>>       _definition.id   '_alias_xref.definition_id'
>>>>>>       _definition.class  Attribute
>>>>>>       _definition.update 2011-01-21
>>>>>>       _description.text
>>>>>>   ;
>>>>>>       Identifier tag of a definition associated with
>>>>>>       an xref code by which to group this tag with
>>>>>>       other tags.  A single tags may be associated
>>>>>>       with multiple xref codes.  An xref code does
>>>>>>       not have to be associated with a particular
>>>>>>       dictionary, nor with a particular DDL format.
>>>>>>       Note that the tag does not have to be a valid
>>>>>>       tag under DDLm tag construction rules, but
>>>>>>       it should be a valid tag under the rules of
>>>>>>       some DDL.
>>>>>>   ;
>>>>>>       _name.category_id alias_xref
>>>>>>       _name.object_id   definition_id
>>>>>>       _type.purpose     Key
>>>>>>       _type.container   Single
>>>>>>       _type.contents    Code
>>>>>>        save_
>>>>>>   save_alias_xref.xref_code
>>>>>>       _definition.id   '_alias_xref.xref_code'
>>>>>>       _definition.class  Attribute
>>>>>>       _definition.update 2011-01-21
>>>>>>       _description.text
>>>>>>   ;
>>>>>>       A code identifying the actual dictionary,
>>>>>>       virtual dictionary or other logical grouping
>>>>>>       to which the identifier tag belongs.
>>>>>>   ;
>>>>>>       _name.category_id alias_xref
>>>>>>       _name.object_id   code
>>>>>>       _type.purpose     Key
>>>>>>       _type.container   Single
>>>>>  >     _type.contents    Code
>>>>>>        save_
>>>>>>   =====================================================
>>>>>>    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, 21 Jan 2011, Bollinger, John C wrote:
>>>>>>>   On Friday, January 21, 2011 8:57 AM, David Brown wrote:
>>>>>>>   [...]
>>>>>>>>   I would like to know exactly what I am voting on.  There seems
>>>>>>>>  to be
>>>>>>>>   general agreement on the information that is needed for an
>>>>>>>>  alias, the
>>>>>>>>   only dispute is the format in which it will appear.  If the various
>>>>>>>>   pieces of information I listed each had their own item, this
>>>>>>>>  would be
>>>>>>>>   agreeable and we could delegate someone to come up with the
>>>>>>>>  requisit
>>>>>>>>   DDLm save frames, but if this information is to be included,
>>>>>>>>  explicitly
>>>>>>>>   or implicitly, in a smaller number of items, then I would like
>>>>>>>>  to see
>>>>>>>>   the definitions and descriptions so that I could understand how
>>>>>>>>  each
>>>>>>>>   piece of information would be retrieved.  John B, can you supply us
>>>>>>>>   with an example of what your normalized item(s) would look like?
>  >>>>>>
>>>>>>>   Indeed, here is the formal proposal I promised, at the end of
>>>>>>>  which is
>>>>>>>   an example:
>>>>>>>   Proposal: Extended Alias Attributes
>>>>>>>   ===================================
>>>>>>>   Introduction / Rationale
>>>>>>>   ------------------------
>>>>>>>   This proposal aims primarily to provide all the ALIAS attributes
>>>>>>>  that several members of this group have recently agreed are needed
>>>>>>>  (at least in principle).  However, attributes that are properties
>>>>>>>  of dictionaries rather than of individual data names are
>>>>>>>  normalized out of the ALIAS category and into the DICTIONARY_XREF
>>>>>>>  category.  The description of the DICTIONARY_XREF category is
>  >>>>>> slightly modified to be explicitly consistent with this usage and
>>>>>>>  with the concept of referencing logical dictionaries that have no
>>>>>>>  independent physical manifestation.
>>>>>>>   Proposed Actions
>>>>>>>   ----------------
>>>>>>>   1) Replace _alias.dictionary_uri with:
>>>>>>>   _alias.xref_code: Specifies a code that identifies the logical or
>>>>>>>  physical dictionary in which the alias is defined.  This serves to
>>>>>>>  categorize and fully identify the alias.
>>>>>  >>    _type.purpose     Identify
>>>>>>>      _type.container   Single
>>>>>>>      _type.contents    Code
>>>>>>>   2) Add these attributes:
>>>>>>>   _alias.dictionary_version: Specifies the first version of the
>>>>>>>   dictionary identified by _alias.xref_code that defines the alias.
>>>>>>>      _type.purpose     Identify
>>>>>>>      _type.container   Single
>>>>>>>      _type.contents    Code
>>>>>>>   _alias.deprecated: Specifies whether use of the alias is deprecated.
>>>>>>>      _type.purpose     State
>>>>>>>      _type.container   Single
>>>>>>>      _type.contents    YesorNo
>>>>>>>   3) In the ALIAS category, replace attribute _category_key.generic
>>>>>>>  with:
>>>>>>>      _category_key.primitive [ '_alias.xref_code'
>>>>>>>  '_alias.definition_id' ]
>>>>>>>   4) Modify the definition of _dictionary_xref.format by changing its
>>>>>>>   _type.contents attribute to "Code".
>>>>>>>   5) Remove _definition.xref_code (its purpose will be served via the
>>>>>>>   alias mechanism)
>>>>>>>   6) Modify the description of the DICTIONARY_XREF category to: "The
>>>>>>>   DICTIONARY_XREF attributes identify and describe logical or physical
>>>>>>>   dictionaries to which items in the current dictionary are
>>>>>>>   cross-referenced using the _alias.xref_code attribute."
>>>>>>>   Comments
>>>>>>>   --------
>>>>>>>   Here is the resulting correspondence between DDLm data names and
>>>>>>>  David's
>>>>>>>   list of alias attributes:
>>>>>>>   "The tag" -> _alias.definition_id (unchanged by this proposal)
>>>>>>>   "the dictionary in which it appears" -> a row/instance of
>>>>>>>   DICTIONARY_XREF, identified by _alias.xref_code (added by this
>>>>>>>  proposal)
>>>>>>>   "the version of this dictionary" -> _alias.dictionary_version
>>>>>>>  (added by
>>>>>>>   this proposal)
>>>>>>>   "the DDL in which the dictionary is written" ->
>>>>>>>  _dictionary_xref.format
>>>>>>>   (type attributes modified by this proposal)
>>>>>>>   "a flag to indicate whether the dataname is deprecated" ->
>>>>>>>   _alias.deprecated (added by this proposal)
>>>>>  >>
>>>>>>>   "a pointer to where the named dictionary can be found" ->
>>>>>>>   _dictionary_xref.uri (unchanged by this proposal)
>>>>>>>   Although this proposal chooses the existing DICTIONARY_XREF
>>>>>>>  category as
>>>>>>>   the normalized location for alias attributes that depend only on
>>>>>>>   dictionary, it would also be possible to instead introduce a new,
>>>>>>>   parallel category for this purpose.  If the _definition.xref_code is
>>>>>>>   merged into the alias feature as I propose, however, then
>>>>>>>   DICTIONARY_XREF no longer has any other purpose.  On the other
>>>>>>>  hand, it
>>>>>>>   is not essential to drop _definition.xref_code.
>>>>>>>   As in my previous proposal concerning _alias.dictionary_uri, the
>>>>>>>  key for
>  >>>>>>  the ALIAS category is expended to a compound one containing the
>>>>>>>   dictionary identifier and the data name.  This allows one data
>>>>>>>  name's
>>>>>>>   appearances in multiple dictionaries all to be aliased to the same
>>>>>>>   defined name, without implying that all possible definitions of
>>>>>>>  the name
>>>>>>>   are aliased.  Essentially, it scopes the alias to the dictionary in
>>>>>>>   which it appears.  DDL2's similar ITEM_ALIASES category is keyed not
>>>>>>>   only to name and dictionary identifier, but also to dictionary
>>>>>>>  version;
>>>>>>>   the last seems needless, even in DDL2, because we can assume that
>>>>>>>  once
>>>>>>>   introduced into a dictionary, data names are not removed or
>>>>>>>  incompatibly
>  >>>>>>  changed.
>>>>>>>   The type attributes of _dictionary.xref_format are changed so
>>>>>>>  that this
>>>>>>>   attribute represents a computer-interpretable code describing at
>>>>>>>  least
>>>>>>>   the DDL compliance level of the referenced dictionary.  Allowed
>>>>>>>  values
>>>>>>>   could be defined so that they encompass other information as
>>>>>>>  well, very
>>>>>>>   much like the proposed tag_style might do.  It might be desirable
>>>>>>>  for
>>>>>>>   DDLm to enumerate allowed values for this attribute, but it would be
>>>>>>>   more flexible to have an external register, such as Herbert
>>>>>>>  proposed for
>>>>>>>   tag_style.  I presently take no position on the best course in that
>>>>>>>   regard, but this proposal does not provide enumerated values.
>>>>>>>   This proposal is offered for comment.  Although I would be
>>>>>>>  willing to
>>>>>>>   have a vote on it as it stands, it could likely be improved.  I
>>>>>>>  am open
>>>>>>>   to changing some of the details if that will contribute to broader
>>>>>>>   acceptance.
>>>>>>>   Example
>>>>>>>   -------
>>>>>>>   loop_
>>>>>  >>    _dictionary_xref.code
>>>>>>>      _dictionary_xref.date
>>>>>>>      _dictionary_xref.format
>>>>>>>      _dictionary_xref.name
>>>>>>>      _dictionary_xref.uri
>>>>>>>      core  '2010-Jun-29'  DDL1  cif_core.dic
>>>>>>>  ftp://ftp.iucr.org/pub/cif_core.dic
>>>>>>>      mmcif '2005-Jun-27'  DDL2  mmcif_std.dic
>>>>>>>  ftp://ftp.iucr.org/pub/cif_mm.dic
>>>>>>>   [...]
>>>>>>>   save_diffrn_standards.decay_percent
>>>>>>>      _definition.id             '_diffrn_standards.decay_percent'
>>>>>>>   [...]
>>>>>>>      loop_
>>>>>>>          _alias.xref_code
>>>>>>>          _alias.definition_id
>>>>>>>          _alias.dictionary_version
>>>>>>>          _alias.deprecated
>>>>>>>          core  '_diffrn_standards_decay_%' . no
>>>>>>>          mmcif '_diffrn_standards.decay_%' . no
>>>>>>>   save_
>>>>>>>   Regards,
>>>>>>>   John
>>>>>>>   --
>>>>>>>   John C. Bollinger, Ph.D.
>>>>>>>   Department of Structural Biology
>>>>>>>   St. Jude Children's Research Hospital
>>>>>>>   Email Disclaimer:  www.stjude.org/emaildisclaimer
>>>>>>>   _______________________________________________
>>>>>>>   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
>>>>>  --
>>>>>  T +61 (02) 9717 9907
>>>>>  F +61 (02) 9717 3145
>>>>>  M +61 (04) 0249 4148
>>>>>  _______________________________________________
>>>>>  ddlm-group mailing list
>>>>>  ddlm-group@iucr.org
>>>>>  http://scripts.iucr.org/mailman/listinfo/ddlm-group
>>>>  --
>>>>  =====================================================
>>>>   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
>>>>  =====================================================
>>>>  _______________________________________________
>>>>  ddlm-group mailing list
>>>>  ddlm-group@iucr.org
>>>>  http://scripts.iucr.org/mailman/listinfo/ddlm-group
>>>  --
>>>  T +61 (02) 9717 9907
>  >> F +61 (02) 9717 3145
>>>  M +61 (04) 0249 4148
>>>  _______________________________________________
>>>  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
>ddlm-group mailing list

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

ddlm-group mailing list

Reply to: [list | sender only]