[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
So, it does not involve touching DDLm at all. The List and Set categories remain inviolate.
Option 3, which does involve touching DDLm because it adds an attribute, simply allows this canonicalisation process to be selective, and is orthogonal to the rest of DDLm.
--
T +61 (02) 9717 9907
F +61 (02) 9717 3145
M +61 (04) 0249 4148
Reply to: [list | sender only]
Re: [ddlm-group] Finalizing DDLm
- To: Nick.Spadaccini@uwa.edu.au, Group finalising DDLm and associated dictionaries <ddlm-group@iucr.org>
- Subject: Re: [ddlm-group] Finalizing DDLm
- From: James Hester <jamesrhester@gmail.com>
- Date: Thu, 15 Apr 2010 12:29:09 +1000
- In-Reply-To: <C7EB96DD.131EC%nick@csse.uwa.edu.au>
- References: <j2p279aad2a1004140029o2ed2a913gb08588493b6d246d@mail.gmail.com><C7EB96DD.131EC%nick@csse.uwa.edu.au>
So, it does not involve touching DDLm at all. The List and Set categories remain inviolate.
Option 3, which does involve touching DDLm because it adds an attribute, simply allows this canonicalisation process to be selective, and is orthogonal to the rest of DDLm.
On Wed, Apr 14, 2010 at 5:59 PM, Nick Spadaccini <nick@csse.uwa.edu.au> wrote:
This doesn’t actually make things clearer or easier James. I will repeat it again.
Strict adherence to the formal specification of DDLm REQUIRES List categories to be presented as looped data, even if there is only one row.
If the IUCr wishes to universally adopt the case where instances of List categories that contain only one row may be presented as a Set category then it can do so as an accepted extension. This of course requires every application writer to necessarily read the dictionary to establish if the data is really a Set category or possibly a List category. Once the IUCr adopts this extension to DDLm within its implementation, I would assume every application writer would be required to adhere to it.Dear all,
Both John and Herb have come out in favour of allowing one-row loops to be unrolled. Nick and I are both sceptical about the value of this idea. We have a few options:
1. Disallow loop unrolling altogether (as in DDL1).
2. Allow loop unrolling for all DDLm dictionaries
3. Add a category-scope DDLm attribute stating that one-row loops in this category and child categories may be unrolled. If it appears in the 'Head' category of the dictionary, it would mean that all categories in the dictionary could be unrolled.
We have not discussed option 3: it basically means deferring the decision on loop unrolling to the dictionary writers. It also means that programmers of generic CIF software will need to be prepared for either behaviour, so in that sense it is slightly more burdensome than option 2.
Unless the silent majority would like to contribute further thoughts on this matter, I suggest that we vote and move on. I discern that the voting so far would be:
Option 1: James, Nick
Option 2: John, Herb
Option 3: ?
(Some comments on John's post are inserted below).
James.
cheers
Nick
--------------------------------
Associate Professor N. Spadaccini, PhD
School of Computer Science & Software Engineering
The University of Western Australia t: +61 (0)8 6488 3452
35 Stirling Highway f: +61 (0)8 6488 1089
CRAWLEY, Perth, WA 6009 AUSTRALIA w3: www.csse.uwa.edu.au/~nick
MBDP M002
CRICOS Provider Code: 00126G
e: Nick.Spadaccini@uwa.edu.au
_______________________________________________
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
Reply to: [list | sender only]
- References:
- Re: [ddlm-group] Finalizing DDLm (James Hester)
- Re: [ddlm-group] Finalizing DDLm (Nick Spadaccini)
- Prev by Date: Re: [ddlm-group] Finalizing DDLm
- Next by Date: Re: [ddlm-group] Finalizing DDLm
- Prev by thread: Re: [ddlm-group] Finalizing DDLm
- Next by thread: Re: [ddlm-group] Finalizing DDLm
- Index(es):