Re: [obix-xml] oBIX 1.1 Issues

[Aaron Hansen <a.hansen@controlco.com>]

I've been negligent, I should have reported on the recurrence rules used 
by Outlook and Google by now - sorry. I'll investigate floating time as 
well and I'll try for tomorrow morning.

1 - Namespace. I feel an obix.org/obix/gregoriantime or similar 
namespace is called for.
3 - In my ignorance, I'll propose that timezone is a unit.
5 - My gut says generically specifying binary data achieves no more than 
staying silent on the subject. I suspect the use will be proprietary and 
therefore we should leave it to the vendor to define it.
6 - I don't think it's worth breaking anything because of a few extra 
chars. A mapping between oBIX and the native model has to occur anyway - 
IMHO this is no big deal.
8 - If we decide we need to support multiple instances, perhaps these 
types could be treated as lists, or some sort of container?
9 - I don't think we need to support the other ical objects right now 
and I don't think freebusy applies to control systems - it's ok if two 
entities want the lights/hvac/door on.


Brian Frank wrote:
>
> The following is a list of issues to discuss for oBIX 1.1 that I’ve 
> run across:
>
> 1) Do we roll the XML namespace version?
>
> 2) Do we allow the use of floating abstime and times? iCalendar allows 
> times to “float” independent of a timezone – is this feature used? If 
> not commonly used, then I would recommend we disallow floating times – 
> it causes a lot of confusion and implementation head-aches. XML Schema 
> technically allows it also, and the current oBIX specification is 
> silent on the issue.
>
> 3) How do we integrate timezones? XML Schema allows no offset 
> (floating), UTC, or an explicit offset. iCalendar disallows an 
> explicit offset, but allows floating, UTC, and a tzid reference. My 
> initial thought is that oBIX requires UTC or explicit offset – but 
> that we also allow the use of a tz facet to reference a timezone 
> definition. Timezone probably becomes more of a core type like Unit, 
> rather than specific to scheduling.
>
> 4) I think we add two new value types date and time. Time will follow 
> the abstime rules for timezone. Literal representations will be based 
> on XML Schema.
>
> 5) Do we need support for a binary value type? iCalendar has it, 
> however recommendation is that it should be referenced out of band via 
> a URI – that is definitely the current oBIX model. Unless we have a 
> known use case, then I would recommend that binary data is required to 
> be identified via a uri object type.
>
> 6) Looking at the oBIX specification, we defined the Weekday and Month 
> enumerations with everything spelled out. That doesn’t seem right to 
> me, especially since most specifications use a three letter 
> abbreviation. iCalendar uses two letter abbreviations for weekdays. 
> Should we change? It means breaking backward compatibility (although I 
> seriously doubt anyone is using them yet).
>
> 7) iCalendar type system is a bit weird: properties, property types, 
> and property parameters. We will likely have to combine property types 
> and property parameters to achieve a more natural type system using 
> contracts.
>
> 8) Some properties can be included multiple times such as RELATED-TO 
> and RRULE. This is problematic if those properties are identified by 
> name, because oBIX forbids duplicate child names. So we have to a) 
> specify those properties as a list or b) specify those properties as 
> unnamed and identity them via their contract.
>
> 9) Do we need to support any component other than VEVENT? Currently 
> I’m thinking that we do not support the VJOURNAL, VTODO, VFREEBUSY, or 
> VALARM components.
>