[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply to: [list | sender only]
Re: Accent escape sequences
- To: "Discussion list of the IUCr Committee for the Maintenance of the CIFStandard (COMCIFS)" <comcifs@iucr.org>
- Subject: Re: Accent escape sequences
- From: Joe Krahn <krahn@niehs.nih.gov>
- Date: Mon, 05 Mar 2007 19:25:59 -0500
- In-Reply-To: <a0623090ac2123f74bcc4@[192.168.10.211]>
- References: <45E72969.1090100@niehs.nih.gov> <20070302101147.GA26353@emerald.iucr.org> <Pine.BSF.4.58.0703020830490.46806@epsilon.pair.com> <45EA0C29.5060604@niehs.nih.gov> <a06230900c20fde7910a9@[192.168.2.101]> <45EC3846.5070001@niehs.nih.gov> <20070305160044.GB13871@emerald.iucr.org> <45EC8BEC.3080501@niehs.nih.gov><a0623090ac2123f74bcc4@[192.168.10.211]>
Herbert J. Bernstein wrote: > The practical reality is that the "usual CIF markup" has been used > in a very large number of existing CIFs on the assumption that > plain text actually means text with that markup. I think we > should formalize that assumption for all quoted strings, making > the current usage "legal". Then for anything else: > > true plain text > CBF binary > TeX > XML > HTML > ... I was not sure how much the markup has been used because the mmCIF dictionaries, which I have been looking at, are essentially limited to the use of Greek letters, degree, and A-ring. In fact, the ring modifier is often omitted. Furthermore, mmCIF dictionaries have markup patterns intended not to be CIF-markup, such as the regular-expression patterns, and do not appear to have an indicator that these are not CIF-markup encoded. A MIME header indicating text/plain would be easy to add. There still needs to be a defined content type for CIF-markup, such as "text/x-cif-markup". It would be needed for a multipart/alternative that had CIF-markup as one type, even if not used elsewhere. > > we would use text fields and MIME appropriate headers. As with email > the burden would not fall on the general CIF parsers, except to the > limited extent of being able to reliably find the end of a text field, > and to deliver whatever was found within the text field to the > higher level application to parse further, if they choose to do > so. CIF writers could invert the path, requiring applications > to deliver properly wrapped MIME ready to put out as text fields. > The CIF writer would add the semicolon quotes, MIME boundary markers and the > content header. The application would be responsible for any additional > headers and the actual content as a byte stream. This division of > labor would allow most CIF software to have no changes in > write logic and only modest changes in read logic, but would allow > applications that need to deliver and to be aware of complex internal > semantics to do so in a CIF environment instead of having to move > over to XML. > The advantage of MIME is that a lot of thought was put into keeping a good balance features, flexibility, and backwards compatibility. It is, in my opinion, an excellent idea, even if imgCIF was not already using it.
Reply to: [list | sender only]
- References:
- Accent escape sequences (Joe Krahn)
- Re: Accent escape sequences (Brian McMahon)
- Re: Accent escape sequences (Herbert J. Bernstein)
- Re: Accent escape sequences (Joe Krahn)
- Re: Accent escape sequences (Herbert J. Bernstein)
- Re: Accent escape sequences (Joe Krahn)
- Re: Accent escape sequences (Brian McMahon)
- Re: Accent escape sequences (Joe Krahn)
- Re: Accent escape sequences (Herbert J. Bernstein)
- Prev by Date: Re: Accent escape sequences
- Next by Date: Re: Accent escape sequences
- Prev by thread: Re: Accent escape sequences
- Next by thread: Re: Accent escape sequences
- Index(es):