<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
Dear all,<br>
<br>
I like the intent of this new flag. It promises to be useful in some
use cases.<br>
<br>
First, let me copy paste here my comment in the <a
moz-do-not-send="true"
href="https://github.com/ivoa-std/TAP/issues/11">Issue #11</a>:<br>
<br>
<blockquote type="cite">
<p dir="auto"
style="box-sizing: border-box; margin-top: 0px !important; margin-bottom: 16px; color: rgb(31, 35, 40); font-family: "Mona Sans VF", -apple-system, BlinkMacSystemFont, "Segoe UI", "Noto Sans", Helvetica, Arial, sans-serif, "Apple Color Emoji", "Segoe UI Emoji"; font-size: 14px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: normal; background-color: rgb(255, 255, 255); text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;">From
the most preferred to the least:<span> </span><code
class="notranslate"
style="box-sizing: border-box; font-family: "Monaspace Neon", ui-monospace, SFMono-Regular, "SF Mono", Menlo, Consolas, "Liberation Mono", monospace; font-size: 11.9px; tab-size: 4; white-space: break-spaces; background-color: rgba(129, 139, 152, 0.12); border-radius: 6px; margin: 0px; padding: 0.2em 0.4em;">no-where</code>,<span> </span><code
class="notranslate"
style="box-sizing: border-box; font-family: "Monaspace Neon", ui-monospace, SFMono-Regular, "SF Mono", Menlo, Consolas, "Liberation Mono", monospace; font-size: 11.9px; tab-size: 4; white-space: break-spaces; background-color: rgba(129, 139, 152, 0.12); border-radius: 6px; margin: 0px; padding: 0.2em 0.4em;">unsearchable</code>,<span> </span><code
class="notranslate"
style="box-sizing: border-box; font-family: "Monaspace Neon", ui-monospace, SFMono-Regular, "SF Mono", Menlo, Consolas, "Liberation Mono", monospace; font-size: 11.9px; tab-size: 4; white-space: break-spaces; background-color: rgba(129, 139, 152, 0.12); border-radius: 6px; margin: 0px; padding: 0.2em 0.4em;">generated</code>,<span><br>
</span><code class="notranslate"
style="box-sizing: border-box; font-family: "Monaspace Neon", ui-monospace, SFMono-Regular, "SF Mono", Menlo, Consolas, "Liberation Mono", monospace; font-size: 11.9px; tab-size: 4; white-space: break-spaces; background-color: rgba(129, 139, 152, 0.12); border-radius: 6px; margin: 0px; padding: 0.2em 0.4em;">unconstrainable</code>.</p>
<p dir="auto"
style="box-sizing: border-box; margin-top: 0px; margin-bottom: 0px !important; color: rgb(31, 35, 40); font-family: "Mona Sans VF", -apple-system, BlinkMacSystemFont, "Segoe UI", "Noto Sans", Helvetica, Arial, sans-serif, "Apple Color Emoji", "Segoe UI Emoji"; font-size: 14px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: normal; background-color: rgb(255, 255, 255); text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;">What
I like with<span> </span><code class="notranslate"
style="box-sizing: border-box; font-family: "Monaspace Neon", ui-monospace, SFMono-Regular, "SF Mono", Menlo, Consolas, "Liberation Mono", monospace; font-size: 11.9px; tab-size: 4; white-space: break-spaces; background-color: rgba(129, 139, 152, 0.12); border-radius: 6px; margin: 0px; padding: 0.2em 0.4em;">no-where</code><span> </span>is
that it is short and immediately meaningful for<br>
users: you know that you should not use<span> </span><code
class="notranslate"
style="box-sizing: border-box; font-family: "Monaspace Neon", ui-monospace, SFMono-Regular, "SF Mono", Menlo, Consolas, "Liberation Mono", monospace; font-size: 11.9px; tab-size: 4; white-space: break-spaces; background-color: rgba(129, 139, 152, 0.12); border-radius: 6px; margin: 0px; padding: 0.2em 0.4em;">WHERE</code><span> </span>with
it. The same for<br>
<code class="notranslate"
style="box-sizing: border-box; font-family: "Monaspace Neon", ui-monospace, SFMono-Regular, "SF Mono", Menlo, Consolas, "Liberation Mono", monospace; font-size: 11.9px; tab-size: 4; white-space: break-spaces; background-color: rgba(129, 139, 152, 0.12); border-radius: 6px; margin: 0px; padding: 0.2em 0.4em;">unsearchable</code>,
although it is a bit too long and requires a bit more thinking.<br>
<code class="notranslate"
style="box-sizing: border-box; font-family: "Monaspace Neon", ui-monospace, SFMono-Regular, "SF Mono", Menlo, Consolas, "Liberation Mono", monospace; font-size: 11.9px; tab-size: 4; white-space: break-spaces; background-color: rgba(129, 139, 152, 0.12); border-radius: 6px; margin: 0px; padding: 0.2em 0.4em;">generated</code><span> </span>is
OK, but I tend to think it is a bit too specific....I don't have
any<br>
example in mind right now, but there may be other reasons why
one should<br>
not use<span> </span><code class="notranslate"
style="box-sizing: border-box; font-family: "Monaspace Neon", ui-monospace, SFMono-Regular, "SF Mono", Menlo, Consolas, "Liberation Mono", monospace; font-size: 11.9px; tab-size: 4; white-space: break-spaces; background-color: rgba(129, 139, 152, 0.12); border-radius: 6px; margin: 0px; padding: 0.2em 0.4em;">WHERE</code><span> </span>with
a given column other than it is generated.<br>
<br>
And similarly to <code class="notranslate"
style="box-sizing: border-box; font-family: "Monaspace Neon", ui-monospace, SFMono-Regular, "SF Mono", Menlo, Consolas, "Liberation Mono", monospace; font-size: 11.9px; tab-size: 4; white-space: break-spaces; background-color: rgba(129, 139, 152, 0.12); border-radius: 6px; margin: 0px; padding: 0.2em 0.4em;">unsearchable</code><span> </span>(actually,
probably worse), a user have to think<br>
about the consequence of a<span> </span><em
style="box-sizing: border-box;">generated column</em>. Here,<span> </span><em
style="box-sizing: border-box;">generated</em><span> </span>is
the way the<br>
data has been provided, but you must have a minimum of database
or computer<br>
knowledge to imagine that a constraint on this column will be
slower than any<br>
other column. A user have to think about it. You do not have
this whole thinking<br>
when you read<span> </span><code class="notranslate"
style="box-sizing: border-box; font-family: "Monaspace Neon", ui-monospace, SFMono-Regular, "SF Mono", Menlo, Consolas, "Liberation Mono", monospace; font-size: 11.9px; tab-size: 4; white-space: break-spaces; background-color: rgba(129, 139, 152, 0.12); border-radius: 6px; margin: 0px; padding: 0.2em 0.4em;">no-where</code><span> </span>;
and actually, you do not have to know the reason why<br>
you should not use this column in a<span> </span><code
class="notranslate"
style="box-sizing: border-box; font-family: "Monaspace Neon", ui-monospace, SFMono-Regular, "SF Mono", Menlo, Consolas, "Liberation Mono", monospace; font-size: 11.9px; tab-size: 4; white-space: break-spaces; background-color: rgba(129, 139, 152, 0.12); border-radius: 6px; margin: 0px; padding: 0.2em 0.4em;">WHERE</code>.</p>
</blockquote>
<br>
Then, I agree with Markus about "mutable"/"immutable". For me, this
conveys<br>
the idea of a data that can or not be changed. It is not natural for
a user to<br>
realize what that means in a context of TAP where no data can be
changed<br>
anyway. And of course, it is not because a column can or not be
changed that<br>
it can or not be constraint.<br>
<br>
I also agree with Joshua and Markus about "computed", "derived" and<br>
"dynamic" although this last one is comparable to "generated".<br>
<br>
In brief, I have no objection to `generated`, but I agree that
better could<br>
probably be found, although I have no better proposition yet.<br>
<br>
Cheers,<br>
Grégory<br>
<br>
<br>
<div class="moz-cite-prefix">On 4/16/26 10:32, Markus Demleitner via
dal wrote:<br>
</div>
<blockquote type="cite"
cite="mid:4bw5r4qgvw7lahkx43aen3mw2bba6b4batx2o3w75pw3hrscrc@qh6qoqh7bimr">
<pre wrap="" class="moz-quote-pre">Dear Joshua,
On Wed, Apr 15, 2026 at 02:45:08PM +0000, Joshua Fraustro via dal wrote:
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">The only things I could offer as alternatives, in order of quality,
I think are:
“computed”
“derived”
“dynamic”
The problem with all three of those is something that we run into
with a number of things in TAP_SCHEMA, which is the distinction
between whether we’re actually describing the data or what a user
can meaningfully do with it.
</pre>
</blockquote>
<pre wrap="" class="moz-quote-pre">
Right. My approach to questions like this tends to be: "Take the
user perspective". This is because the VO is still dominated by data
providers, and hence that perspective tends to be under-represented.
More importantly, my experience with VO standards is that they
are best when they are constructed from what the users are supposed
to do with them and worst when data providers think about all the
great things they would want to tell their users.
That inspired my first suggestion, unconstrainable.
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">If it’s about the data, the above might be a hair better. But if
it’s simply about whether a user can filter on the data,
might I suggest just, filterable ?
</pre>
</blockquote>
<pre wrap="" class="moz-quote-pre">
I don't like filterable much because that's the default and we'd have
to put it into the flags of most columns, which I'd like to avoid.
The special case hence would be "unfilterable", which is almost as
long and ugly as unconstrainable but IMHO a bit less precise because
it's constraints that you can't write (in ADQL), whereas I think
"filter" just doesn't exist in VO lingo (outside of VOEvent?) yet.
In the PR, the cute option "no-where" came up. The more I think of it,
the more I like it. Admittedly, it's strongly geared towards
SQL-like query languages, but I don't consider that a major wart, as
that's the model for almost anything out there (cf. SPARQL). And
it's something that shouldn't cause any false associations.
As to Jon's proposal “immutable”/“mutable”... Well, "mutable" has a
strong meaning already that is quite a bit away from what we are
struggling with here. So I'd prefer generated over that.
Well: I've updated the PR and rebased it to a previous VODataService
PR that already had all the whitespace noise (thanks, Mark) so it's a
lot more readable now. I've kept "generated" as literal for now but
changed the definition to Pat's proposal:
values in this column are generated during output and query
constraints cannot be used
While I think that's *a bit* overspecific because I'd like to use
this flag also when I, say, store some binary data in a database
column and want to tell people there's no meaningful way to
constraint that for the time being, it feels more understandable to
me than my previous attempt.
So... are there people who absolutely couldn't live with "generated"?
And are the improvements on Pat's definition?
Thanks,
Markus
</pre>
</blockquote>
<br>
</body>
</html>