Closed msdemlei closed 11 months ago
Ah... @pdowler – would you have a look at this?
On Wed, Apr 12, 2023 at 02:42:40AM -0700, Mark Taylor wrote:
@mbtaylor requested changes on this pull request.
"real" is not a VOTable datatype. The datatype attributes here should be "float" or "double".
Ouch. I suppose some trickery to let a computer validate snippets would be a valuable addition (probably to ivoatex as a whole). The main reason I've not tried to do something like that is that I don't have useful ideas for how to provide the context in which to validate the snippet.
Anyway, for this I've put in float. Thanks!
Content looks OK now but yes wait for @pdowler to comment.
On machinery for validating snippets of XML/VOTable, see ivoatexDoc Sec 3.11.4, which has an example very like this one. I'll admit it is a bit fiddly to do it for lots of small examples though.
On Wed, Apr 12, 2023 at 03:10:38AM -0700, Mark Taylor wrote:
Content looks OK now but yes wait for @pdowler to comment.
On machinery for validating snippets of XML/VOTable, see ivoatexDoc Sec 3.11.4, which has an example very like this one. I'll admit it is a bit fiddly to do it for lots of small examples though.
Yeah, this is not something I'd want to do for a larger number of examples (in particular since it results in two extra files per snippet). For source readability, I'd also really like to keep the snippets inline if at all possible.
I've thus been thinking the other way round: Have a little script that pulls out examples based on some markup and then validates these. I feel that that markup should somehow specify the context in which to validate the snippet, and that's where I always get stuck.
The description is technically correct in as far as it is consistent with the way xtype="circle" uses MAX for describing input params (for services via datalink service descriptor) aka minimum enclosing/spanning circle. The implications are a little different and it seems less useful in the context of a field (column full of circles) because a circle is a poor way to aggregate a set of circles and convey something useful about the set. There are several useful aggregates that tell the client about the circles in the column, but a single MAX interpretation is probably not one of them.... in an input PARAM, MAX isn't trying to aggregate.
So, the language here is consistent with the "xtype intepretation of MIN/MAX" idea we agreed on to resolve the usage for xtype="interval", but it also illustrates that maybe these interpretations that I'm supposed to write into WD-DALI-1.2 works for input PARAMs but not for FIELDs (where works means useful). I don't think an interval MIN/MAX example would expose that very well because 1D is, well, simple enough that it would usefully convey "coverage".
aside: the input param usage in service descriptors was driven by the use case of "provide useful info so client can do ops" (eg SODA) and we just tried to use existing VOTable features... it's not even the intended use of PARAM :-) Maybe using existing VOTable features was short-sighted and another solution supported by a VOTable enhancement would have been better
Le 12/04/2023 à 18:15, Mark Taylor a écrit :
@.**** approved this pull request.
— Reply to this email directly, view it on GitHub https://github.com/ivoa-std/VOTable/pull/38#pullrequestreview-1381664594, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMP5LTHADF56WITRDNUGR4TXA3IJZANCNFSM6AAAAAAW3MTN7E. You are receiving this because you are subscribed to this thread.Message ID: @.***>
OK for me.
Still have to decide whatb to do in the case of xtype= interval (two options to discriminate in the context of SODA erratum 3)
On Wed, Apr 12, 2023 at 09:12:42AM -0700, Patrick Dowler wrote:
The description is technically correct in as far as it is consistent with the way xtype="circle" uses MAX for describing input params (for services via datalink service descriptor) aka minimum enclosing/spanning circle. The implications are a little different and it seems less useful in the context of a field (column full of circles) because a circle is a poor way to aggregate a set of circles and convey something useful about the set. There are several useful aggregates that tell the client about the circles in the column, but a single MAX interpretation is probably not one of them.... in an input PARAM, MAX isn't trying to aggregate.
Well... as you know I've always considered this whole magic MAX thing an ugly abuse of MAX, and I still wish we hadn't gone down that road. I hence share your feelings that the whole thing is not great, but, well, it's what we've built, no? So... are you saying it shouldn't go in in this way? If so, what would you suggest instead? Should we do a Param and explain about SODA? If so, could you perhaps take over this PR and write some text?
Me, I'd still maintain the example as it is is about as reasonable as the whole magic MAX scheme...
On Wed, Apr 12, 2023 at 09:34:23AM -0700, François Bonnarel wrote:
Still have to decide whatb to do in the case of xtype= interval (two options to discriminate in the context of SODA erratum 3)
Except that that's for DALI to decide, not for VOTable: Let's not make this mess any worse by inventing even more rules, so: I'm 99.99% in favour of the standard array interpretation.
I definitely do not think providing MIN/MAX for a FIELD where the column contains some kind of geometry is useful because those aggregate concepts don't really apply to that scenario like they do for scalar values.
As for PARAM, the generic usage in VOTable is that this is a constant value... a plain constant doesn't need a MIN/MAX to describe it. The usage in the service descriptor inputParam was already a bit of abuse, but I recall there was prior art for that usage. If a PARAM to describe an input is sanctioned VOTable usage then we can add some simple examples, but if it's something that other standards (DataLink, iirc SIA1, maybe others) hacked together then I'm less sure it belongs here.
On Thu, Apr 13, 2023 at 11:03:12AM -0700, Patrick Dowler wrote:
then we can add some simple examples, but if it's something that other standards (DataLink, iirc SIA1, maybe others) hacked together then I'm less sure it belongs here.
I frankly don't care much either way, but I'd like this to get out of the way. So... are you saying we should just close #32 and this PR? If so, does anyone else object to that?
I am going to write up the DALI changes about MIN/MAX for some xtypes and create a PR today. I think once I've done that it will help us know what to put or not put into the VOTable doc. So let's hold off until I do that.
Will add link to that PR here when done.
OK, I have written as much text in DALI that I can and keep it general purpose. This is included in my current work tweaking the MOC xtype (because I forgot to check that it had not been merged):
On Mon, Apr 17, 2023 at 11:34:14AM -0700, Patrick Dowler wrote:
OK, I have written as much text in DALI that I can and keep it general purpose. This is included in my current work tweaking the MOC xtype (because I forgoit to check that it had not been merged):
Hm yes... what does that mean for this PR? I understand you still don't like the circle example, at least with a field. Would you be ok with this PR if I changed the FIELD to a PARAM? If not, what else would you suggest as an example for flamboyant MAX?
Yes, I think changing the maximum circle example to an input PARAM would be better.
If you feel OK about having a forward reference to the usage in datalink service descriptors or SODA, you could explain the meaning of the "maximum circle" in that context. That's probably a better example and one based on actual use. It will say the same thing that WD-DALI says (in PR) but I think it's ok to repeat such explanations/examples when they illustrate use cases the spec supports.
If you want to make that max circle example more explicitly match the SODA use case, also change to PARAM name="circle" (because in SODA name="pos" datatype="char" arraysize="*" is something else).
On Tue, Apr 18, 2023 at 02:59:53PM -0700, Patrick Dowler wrote:
Yes, I think changing the maximum circle example to an input PARAM would be better.
Ok, I've force-pushed a change to that effect. Can everyone live with this? Frankly, I doubt we'll ever find pretty language for an ugly wart like the mad MAX-es (I wish I had thought of that particular pun before).
Looks good to me.
Can I bump this? @pdowler, can you perhaps do a formal review to save Tom the pain of force-merging? Thanks!
This is intended to address bug #32.