[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply to: [list | sender only]
Re: [ddlm-group] THREAD 3: The alphabet of non-delimited strings.
- To: Group finalising DDLm and associated dictionaries <firstname.lastname@example.org>
- Subject: Re: [ddlm-group] THREAD 3: The alphabet of non-delimited strings.
- From: Nick Spadaccini <email@example.com>
- Date: Fri, 09 Oct 2009 23:32:15 +0800
- Authentication-Results: postfix;
- In-Reply-To: <20091008203654.H16544@epsilon.pair.com>
As specification (which I have said must be strict, notwithstanding parser implementations may be individually more liberal) I will propose 1.2, 2.3 with the added restrictions on "" and '', and ascii-fied unicode in strings. With an addition that the specification can suggest/implore (insert whatever) cif WRITERS under the new specification should pad at least one space between tokens. In that way old parsers should still handled these strings the same way. I think this is really redundant because I think all writers will pad tokens anyway (all my parsers do). In fact I know of no auto code generator that does not pad tokens, even though it is not required under the strict specification. I want to move forward on this because this has been 12 years in the making and we are still at the syntax discussion phase, even though the Perth group has shown proof of concept systems. The problem with those is we worked in a restricted syntax so we could do things, now we need that enshrined. As for your comment on binary Herb, we will need to discuss this when I am up at Dowling. I didn't think I was excommunicating imgCIF but I have not been in that loop of late so I may be missing something. I thought imgCIF was a pure ascii equivalent of CBF, so I see my solution as maintaining the status quo. CBF has a pure ascii header followed by binary blocks, tagged by a "smart comment(s)", does it not? I see UTF-8 embedding as creating situation where the pure ascii header of CBF will now have the possibility of binary mixed in. I would think this will prove a problem for people. But we can discuss the details of this next week. As for voting, I get the feeling Brian and John are going to take a back seat for various reasons. It may only be a vote of 3? At the moment with James on leave it is just me and you, dude. I think however with my time at Dowling we two will get some productive movement on this. On 9/10/09 8:45 AM, "Herbert J. Bernstein" <firstname.lastname@example.org> wrote: > Dear Nick, > > P.S. From your comments about binary, it sounds as if you intend to > "excommunicate" imgCIF from DDLm. I think that would be a mistake. imgCIF > will benefit greatly from the use of methods, but at worst, I can always > go back to the original name: imgNCIF, where the N stands for "not", and > use methods without the blessing of it being officially a "CIF" > dictionary. 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 email@example.com http://scripts.iucr.org/mailman/listinfo/ddlm-group
Reply to: [list | sender only]
- Re: [ddlm-group] THREAD 3: The alphabet of non-delimited strings. (Herbert J. Bernstein)
- Prev by Date: Re: [ddlm-group] THREAD 3: The alphabet of non-delimited strings.
- Next by Date: Re: [ddlm-group] THREAD 3: The alphabet of non-delimited strings.
- Prev by thread: Re: [ddlm-group] THREAD 3: The alphabet of non-delimited strings.
- Next by thread: Re: [ddlm-group] THREAD 3: The alphabet of non-delimited strings.