Bringing VOEvent v2.0 home to roost

[Matthew Graham]

Hi,

On Mar 15, 2011, at 2:36 PM, Rob Seaman wrote:

> As Matthew says, how would this interact with the registry description of the corresponding VOEventStream?
> 
> So basically you are saying that type should not be a URI, but rather a mime-type.  Perhaps such an attribute would better be called just "mime".  And there should also be a role attribute.  In both cases we would need to define the acceptable values either explicitly, or perhaps via the registry?
> 
> Or perhaps a URI-typed "type" attribute in addition?  Or is omitting this the real benefit?
> 
> Once we sort out the options, perhaps it's better to move forward from the v1.11 language:
> 
>> 	3.9.2 type — The type of the document. Allowed values are "voevent", to reference a previously issued VOEvent packet (in whole or in part);"url", for a MIME-typed URL; "rtml", to refer to an RTML [15] document (typically the one used to drive the telescope that made the observation(s) resulting in the event), or — "ivorn", to refer to IVO resources. The default value is "url".
> 
> In the absence of rapid convergence, the chair suggests we leave the v1.11 language in place and hold the issue over for v2.1.

I'm sorry but I disagree with this decision. There is nothing particularly new in dereferencable URIs being used for typing and it's not exactly rocket science. In practice, a small subset will almost certainly be in common usage and you can hardcode these if you want but an enumerated list is a real headache and not extensible without some form of versioning.

I'm also somewhat concerned that this discussion is happening with a specification that has been promoted to PR. This does rather suggest that it is not mature enough.

	Cheers,

	Matthew


> 
> --
> 
> On Mar 15, 2011, at 1:56 PM, Mike Fitzpatrick wrote:
> 
>> On Tue, Mar 15, 2011 at 1:37 PM, Rob Seaman <seaman at noao.edu> wrote:
>> Would you replace a URI type with a static string (and maybe some enumerated list or UCD-like process for adding entries to the list), or would you add a general string-valued mimetype and keep the URI around or what?  If there are thousands of events daily, couldn't the app cache the type URIs?
>> 
>> If I were processing a stream, the caching would be an option (not
>> a pleasant one in light of what should be a small change to the PR
>> doc), if I were a SEAP application mining repositories then perhaps
>> not so much.
>> 
>> Note this is separate from my comment about the use of <Reference>
>> as a child of <Table>:  A mime-type attribute would tell me *what*
>> the external object is, but not *how* (or why) it's related to the parent element
>> (e.g. is it supplemental documentation of the observing strategy,
>> instrument design characteristics, a formal definition of say a <Param>,
>> or is it a related dataset as in my example.  Let's call this a 'role'
>> attribute that accepts some list of values like 'documentation', 'definition',
>> 'related-data' or somesuch.
>> 
>> With a mime-type and role attribute on <Reference> I think it would be
>> much easier for apps filtering streams or mining repositories to know
>> when/whether they need to access the external content.  Otherwise, 
>> I think apps have no choice but to simply access *everything* (which
>> may be a huge amount of data), or simply ignore the <Reference>.
>> 
>> -Mike

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