<div dir="ltr"><div dir="ltr"><div>Dear Markus,</div><div><br></div><div>Thank you for the historical explanations but still the question of <i>how  to specify that a <FIELD> is made of ascii characters only</i> has no answer in the current VOTable draft… But apparently nobody cares ?</div><div>Cheers, François</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">Le lun. 6 juil. 2026 à 14:48, Markus Demleitner via apps <<a href="mailto:apps@ivoa.net">apps@ivoa.net</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Dear François,<br>
<br>
On Thu, Jul 02, 2026 at 08:51:43PM +0200, Francois Ochsenbein via apps wrote:<br>
> that removing the possibility of specifying that a non-numerical column<br>
> is made of ascii-only characters does not raise more comments or<br>
> concerns?… A few more comments embedded below:<br>
<br>
Oh, don't worry: There has been plenty of discussion.  I've been<br>
trying to *somehow* improve the unsatisfying VOTable char situation<br>
since at least 2012, and these attempts got stuck numerous times.<br>
Mark's valiant attempt is the result of a dedicated plenary (IIRC)<br>
in College Park.<br>
<br>
I will freely admit that we'd certainly not design this like this if<br>
we started from scratch.  But I am fairly sure we have reached a<br>
result that is the least bad of all the various options we have<br>
looked at over time, and that includes the nD-array decoding that<br>
*is* abominable.<br>
<br>
In the end, how I'd frame the question is: What's the least<br>
unexpected thing a VOTable parser can do when encountering characters<br>
>= 0x80 in VOTable char?  I give you that in 2005, multiple answers<br>
were justifiable, and the "reject" answer you gave turned out to be<br>
the wisest.<br>
<br>
These days, and I'd be *very* surprised if this were different 20<br>
years from now, it is as clear that it'll be UTF-8 as it was in 2005<br>
that 7 bit characters are ASCII.  Sure, back then there still was<br>
EBCDIC and other horrors.  You were wise enough to keep this<br>
possibility out of VOTable.<br>
<br>
Today, despite all the uglyness involved, it is wise to finally give<br>
these eighth bits a meaning; and utf-8 is the least surprising thing<br>
we can do today, despite all the trouble that this brings with it.<br>
<br>
One minor remark, though:<br>
<br>
> ==> On 2026-06-29 à 13:02+0100,<br>
>       Mark Taylor <<a href="mailto:m.b.taylor@bristol.ac.uk" target="_blank">m.b.taylor@bristol.ac.uk</a>> wrote:<br>
> >Nearly all software is written these days in an environment in which<br>
> >strings are assumed Unicode, but that doesn't mean that programmers<br>
> >spend their time worrying about the fact that Aries is represented<br>
> >by two code points or that there is no unique way to encode something<br>
> >that looks like an Omega or accented characters.  Comparison of two<br>
> >UTF-8 sequences for equality *is* an easy operation, though it will<br>
> >not necessarily yield true for two strings whose pixel rendering is<br>
> >identical.<br>
> ><br>
><br>
> Sorry to disagree with the "transparency" of Unicode in the various<br>
> languages: for instance length("άβγ♈︎♉︎😊𝕏") gives 12 in Javascript<br>
> or Java, while Python3 or awk return 10, which is the correct number of<br>
> Unicode code-points in this string(*). Similarly extracting a substring<br>
<br>
Ummmmm... that's a function of the *VOTable* library: Will it do the<br>
UTF-8 de- and encoding for you or won't it?  I expect most will, and<br>
then any sensible len-type function will be the number of unicode<br>
codepoints, independently of the language.<br>
<br>
When a VOTable library doesn't do the decoding, the length will be<br>
the number of bytes in front of the first 0x00 or arraysize,<br>
whichever is smaller -- again, this is a function of the library and<br>
not of the language.<br>
<br>
That the language objects you get from a parse function depend on the<br>
library is nothing new; it's been this way with xtypes for a long,<br>
long time (example: xtype="timestamp": Do you get a string or some<br>
structured time representation?)<br>
<br>
So, I'm fairly confident that we won't see major desasters; a certain<br>
problem can be very old VOTables that use some legacy 8-bit encoding<br>
-- but thanks to the no-eighth-bit rule that's been in place so far<br>
these have been broken all the time, and well-behaved VOTable<br>
libraries will have displayed question marks -- which they will, in<br>
all likelihood, still do.<br>
<br>
Thanks,<br>
<br>
            Markus<br>
<br>
</blockquote></div></div>