Bringing VOEvent v2.0 home to roost

[Rob Seaman]

Hi Mike,

> The graphic in the v2.0 PR draft is illegible in the PDF version.

It zooms ok for me.  Perhaps the embedded graphic should be shrunk since it isn't readable anyway.  This seems a broader issue than VOEvent for any of the IVOA documents that began life as HTML and are now supposed to be delivered as PDFs.

> What I had  in mind were simple text tables of element/attributes as was done in the VOTable REC.

We'll take a look.  On the other hand schema diagrams seems a broader issue than the IVOA.

>         Does this need to be camelCase,
> 
> Perhaps it should have been "datatype". However, I have written a bunch of code against "dataType" and would prefer not to change it. It was a week of great enthusiasm for camelCase, since deflated.
> 
> It's not a major issue, but I don't think the existence of code doing something
> else has been used as an excuse for not making changes in a PR doc .....

I wouldn't say there has been a groundswell as yet one way or the other.  More dromedaries need to speak up.

> 
> Any data object can be linked as a Reference, including Tables. The Reference can point to a VOTable or a FITS table or a text table. You can have *either* <Table> to include it in the packet, *or* <Reference> to point to an external data object. Anyway, I just removed the sentence "It should be noted ..." as it is obviously confusing.
> 
> Maybe I misunderstood your reply, but the latest draft still allows a <Reference>
> within a <Table> so my original comment still stands.

I hadn't previously understood you to be commenting on references in tables and I'm not sure I understand what you're talking about yet.  Perhaps an example?

> One last comment:  As an application developer I'm not sure I find the
> <Reference> all that useful.  I understand the desire to be able to link to
> any external content, but what I'd like to see is something like a mime
> type attribute so my app can decide whether it can handle whatever 
> the data might be.  The 'uri' is essentially free text, you say it's in a URI
> syntax but a value like "http://.../data-models/#h-filter-image" is
> meaningless unless the app knows what to expect (or just treats it
> as bulk data for download).  The case for a reference to another event
> packet is pretty clear, but how do you expect apps to use e.g the
> <Reference> in a <Param> ???

It's heartening to see comments from the point of view of using VOEvent in applications.  One aspect of references is similar to the description element, as a way to supply human readable (or clickable) content.  Whether this is useful may depend on the application.

VOEvent represents the trade-off of transient alert "telegrams" between human-readable and machine-parseable text.  An early choice was to express values as params rather than explicit schema elements and attributes.  The table mechanism in v2.0 is an evolution of this.  An attempt was made to introduce more explicit machine-parseable elements into the schema via SimpleTimeSeries.  Objections were raised that this was too heavy a schema load.  The objection here appears to be that references are too lightweight.  Maybe so, but they haven't changed that much since v1.0 of the standard.

Are your last couple of comments just suggesting that <Field> not be permitted to contain <Reference>?  Perhaps Roy can comment.

Wherever a reference or other URL/URI appears, I would think the obvious app behavior would be to provide a clickable link, likely via a browser.  If the app doesn't have a GUI, presumably just pass the reference to the output packet (if any).

Rob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/voevent/attachments/20110315/6ce41830/attachment-0001.html>