Discussion List Archives

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

Re: Accent escape sequences

Brian McMahon wrote:
>> The advantage of a simple escape mechanism, like the current scheme, is
>> that it is fairly easy to read directly. The disadvantage is that it has
>> limited abilities. With MIME, the multipart/alternative could be used,
>> where simple ASCII escapes are combined with a more accurate version
>> that is not directly readable. This give the advantages of both forms.
> In principle, this is a great idea. Consider the CIF dictionaries,
> where the pure-text _definition field sometimes carries inventive
> representations of maths (e.g.
> http://www.iucr.org/iucr-top/cif/cifdic_html/1/cif_core.dic/Irefine_ls_restrained_S_gt.html )
> that have to be reverse-engineered into something more useful (e.g. TeX)
> when typesetting these for International Tables. It would make it
> easier to keep these representations in sync if they were both
> transported as multipart/alternative content in the same text field.
> But ... this does come at the expense of significantly more
> complexity in applications that need to do something with the
> content of text fields. Most scientific CIF applications (the
> ones that work on the data) won't be affected - they just skip
> over text fields. The others will need to have the ability to
> parse and extract MIME content (not too difficult), but also
> to *write* proper multipart content, and that's not necessarily
> so easy if you're to provide tools that ingest content from
> different input streams (TeX-savvy editors, html editors,
> clipboards...). In practice the Acta office doesn't see a
> critical mass of content provision to justify this complexity
> at this stage (it's still really only Acta C and E that use
> CIF text fields extensively, and they're catered for through
> publCIF). Having said which, there's no harm in working through
> the details of how such a system could operate.
As long as the multi-part processing is optional, it should not be a
problem. The extra effort then only needs to be done for those cases
where the content is sufficiently complex that the software is already
dealing with the extra complexity.

> Going back to Joe's original wishes to rationalise and perhaps
> extend the existing CIF markup, it's important also to remember
> that some data items will also occasionally require markup for
> simple string fields - e.g. how to markup the "alpha" Wyckoff
> position in the symmetry CIF dictionary? The use of
> the '\a' digraph in
> http://www.iucr.org/iucr-top/cif/cifdic_html/2/cif_sym.dic/Ispace_group_Wyckoff.letter.html
> clearly derives from the "usual" CIF markup for alpha, but that is
> nowhere made formally clear. It looks like we need unambiguous
> markup rules in these cases too.
Are you saying that the current CIF markup is defined only for
multi-line text? If so, the description sentence is an example where
'\a' needs to represent the character sequence in the non-markup form
(not converted to '<alpha>').

> (I'm hoping to see our publCIF developer later this week so that
> we can discuss the specifics of the proposal Joe posted recently.)
> Brian
When I first looked at this, I thought it would be sufficient to covert
the Latin1 and Latin2 character sets. But, these do not include the
over-bar already defined. I also realized that RFC-1345 covers a lot of
this. It defines 2-character sequences for most Latin characters, 3-4 in
some cases, and longer sequences for languages like Japanese. Maybe it
would be a good goal to cover all of the Latin characters from the
2-letter set from RFC-1345?

Most of those 2-letter codes have the alphabetic character first, then
the modifier. These would be quite similar to the CIF markup by swapping
the two characters, and with a few differences in the modifiers, such as
zero instead of % for ring-above. It also adds Hook (2) and Horn (9)
modifiers. It would be nice to use the RFC-1345 set of modifier codes
for increased standardization. Any chance of having CIF markup "version
2" with some incompatible changes? Maybe it is OK in the context of
including Content-Type headers?

In the case of 2 alphanumeric codes it is simple to map RFC-1345 to
'word based' CIF codes, such as "\\ae " for the ae ligature.

Joe Krahn
comcifs mailing list

Reply to: [list | sender only]
International Union of Crystallography

Scientific Union Member of the International Council for Science (admitted 1947). Member of CODATA, the ICSU Committee on Data. Member of ICSTI, the International Council for Scientific and Technical Information. Partner with UNESCO, the United Nations Educational, Scientific and Cultural Organization in the International Year of Crystallography 2014.

ICSU Scientific Freedom Policy

The IUCr observes the basic policy of non-discrimination and affirms the right and freedom of scientists to associate in international scientific activity without regard to such factors as ethnic origin, religion, citizenship, language, political stance, gender, sex or age, in accordance with the Statutes of the International Council for Science.