There seem to me important questions of principle here.

1. Whose interests are we caring about? Who are the envisaged users of this standard? If it is mainly librarians, then, fine, if librarians are happy with MARC (that's "if") then fine, stick with "u". I'm not a librarian and I have never heard of MARC. If it's not mainly librarians, but members of the wider public, then the question of "u" or"x" seems to me simple to determine. Jakob already gave good examples of the use of "x". To me, "x" is more intuitive. Agreed, intuition is relative to people's experience. But are we going to propose a standard based on the intuitions of a small set of people, or on some more representative sampling of the intended users? In principle it wouldn't be difficult to do a survey of a selection of people who fall into the categories of intended users of the specification. So, surely, the argument here should continue by giving reasoned opinion about who the intended users are, or by reference to classes of intended users as set out in an agreed draft.

2. What are we trying to do, anyway? It's easy to lose sight of this kind of big question, when considering minor details. I was thinking about this with reference to the calendar question. The answer I would give (not assuming anyone else would concur) would be something like "we are trying to formulate a standard specification for ways of representing dates and times in ways that are, or have been, common; in formats that have as clear as possible a relationship with the formats originally used" (i.e. e.g. not involving complex calculation, but possibly involving simple translation)

In the present discussion of "x" v "u", it is clear enough from the discussion that both conventions have in fact been used. In these cases obviously to get a standard, ideally we need to standardise on one of these, because the conversion from one to another is simple transliteration. It is possible within a standard to have alternatives for the same thing, but I don't think anyone would say this was ideal. Having said that, ISO 8601 has many different alternative formats to represent the same date or time. So we could have "u" for librarians and "x" for everyone else... :-)


On 23 November 2010 13:31, Edward C. Zimmermann <[log in to unmask]> wrote:
On Tue, 23 Nov 2010 11:44:16 +0100, Jakob Voss wrote
> Edward C. Zimmermann wrote:
> > I personally do not like x. I see nothing to gain from using x.
> I summarized the arguments in my first mail. But arguments about
> notation always depend on cultural background. We could also use

Its about information processing and computers and not about "cultural

> random characters or codes instead of '~', '?', '(', ')' etc. It's

These characters are not random.

> mostly about what you consider more convenient in which context.
> > 1) MARC21  (the harmonized US and Canadian MAchine-Readable Cataloguing
> > standard) uses u for uncertain or missing digits in its date fields. That
> > format is the North American standard. It won't go away and its significance
> > is not limited to North America. This means that many of us must already
> > support u in this function.
> So your context is MARC21, and in this context there is an argument
> for using the letter 'u' in this place. But everywhere outside the
> heavily outdated world of MARC, this practise is unknown and 'x'

And those books too in the old library.. all old and outdated... Who needs
them when one has Wikipedia and Google :-)

What alternative to you offer to MARC?

> would be the more natural choice.

There is no wide practice of using 'x' represent an unknown cell or space to
fill. In fact, if one wants to appeal to cultural semantics... 'x' is really
the wrong character.

The cultural information processing heritage of 'x' stems from typewriters and
overtyping: the act of "crossing out". Its to strike out or remove something.

There are other cultural semantics for 'x'. Our 'x' as taught in school
algebra--- and its not just x but also y, z, alpha, beta, delta and omega---
is not really a concrete object but in the sense of Descartes an
abstraction--- see also Arabic and Greek mathematics (of which the selection
of 'x' had its rooting). The symbol is also taught in school as concrete
multiplication: 10x5 (abstract multiplication given the common use of 'x' in
school textbooks for variable names demands the use of other notations for

'X' is also the symbol or enemy, ritual friend (Homer: xenos) but also
crucifixion, the spot on the map where the treasure is buried, a person's
signature. the number 10 and .... lets not forget XXX as ...

> > 2) Worse still is the observation that x is also commonly used in the first
> > position to represent hexadecimal codes.
> I don't see this as a problem, as we don't support hexadecimal codes
> in the standard. Escape sequences do not use a single 'x' anyway,

If I announce that something is a date perhaps... But how do we teach
computers to recognize dates?

>  but some other escape character like backslash or ampersand,
>  combined with 'x' or some other characters.
> > What does 'x' deliver other than, at best, additional complication? Our
> > formats are, after all, primarily for computers. In library systems characters
> > such as '#', 'u' and '?' have been used. The character 'u' is not my
> > favorite--- but understandable in MARC21 given the heavy use of punctuation
> > characters for significant functions--- but clearly preferable to 'x'.
> >
> > In this context I think we might also want to consider the difference between
> > unknown digits and a placeholder for a date (fill characters such as | in
> Sorry, but arguing with special properties of MARC is like arguing
> with special properties of EBCDIC, troff, or any other standards

EDCDIC is a proprietary character encoding standard that was once advocated by
IBM. Its been widely replaced by other encodings and standardization of
keyboards--- back into the 1970s on many computers one needed a specific
proprietary keyboard to program them (this was one of the chief motivations
behind BCPL and why it grew with the ARPAnet).

MARC21 is a current accepted standard for the interchange of bibliographic

Fortran too is "old school" from the 1950s.. over 50 years old and with a vast
legacy. Its still the primary language for a large body of applications in the
scientific community!

> from the 1960s. I would even argue that having a special property in
> MARC, it is a good indicator that you do not want it in any serious
> current application. Or more drastically: MARC is a pest, that
> current Date/Time standards should not be infected with.

You keep attacking MARC--- and MARC21 is where a lot of the MARCs are now
headed--- but what replacement have you suggested?

> Jakob
> --
> Jakob Voß <[log in to unmask]>, skype: nichtich
> Verbundzentrale des GBV (VZG) / Common Library Network
> Platz der Goettinger Sieben 1, 37073 Göttingen, Germany
> +49 (0)551 39-10242,


Edward C. Zimmermann, NONMONOTONIC LAB
Basis Systeme netzwerk, Munich Ges. des buergerl. Rechts
Office Leo (R&D):
 Leopoldstrasse 53-55, D-80802 Munich,
 Federal Republic of Germany
Umsatz-St-ID: DE130492967

Simon Grant
+44 7710031657