VOEvent v2.0 is ready for prime time

[Frederic V. Hessman]

One last try:

	- throw out "name"
	- change the name of "type" to something else and leave it in the  
spec for things like mime types (Norman's "mimetype" is great).  Or  
simply dump this attribute alltogether.
	- add an officially semantic attribute (e.g. with the name "meaning")  
with the strict content specification "anyURI" with the intent of  
using controlled vocabularies of some type.

Rick

On 23 Mar 2011, at 17:54, Rob Seaman wrote:

> Hi Rick,
>
>> The "uri" attribute is fine.
>>
>> Leaving things as they orginally were means
>>
>> 	- having a useless "name" attribute;
>> 	- having a "type" attribute commonly used for thousands of other  
>> things and hence a mess for practical-minded people like Roy.
>>
>> That's why I'm arguing to drop "name" and change the name of "type"  
>> to something more specific and hopefully content-controllable.
>
> So your suggestion is:
>
> 	deprecate (or ignore) type and name attributes
> 	add another type-like attribute
>
> This is structurally equivalent to my suggestion of adding a single  
> attribute.  Is one new attribute all you need?
>
> Norman, what are the (structural) details of your suggestion?
>
> Ideally a v1.11 packet will be similar enough to a (variation of) a  
> v2.0 packet that tools we currently have won't necessarily balk.   
> Which is to say that I would prefer to deprecate (or ignore) current  
> attributes, even if the v2.0 "way" is quite different.  Backwards  
> compatibility is something of a metaphysical concept with XML  
> schema, but let's not ignore the needs of all the projects that have  
> deployed on top of v1.11.
>
> Keeping the semantic metaphysics (certainly very interesting) to a  
> minimum, what are the precise options we are considering?  Attribute  
> name(s), value(s)?  How many options are there on the table?
>
> There is a consensus here, but we won't see it until the details of  
> the different suggestions are compared point-by-point.
>
> Rob