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
> background".
> > 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
> multiplication).
> '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
> MARC).
> >
> > 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
> information.
> 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