[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [obix-xml] oBIX 1.1 Issues
>> 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. What if I want to ask "Who left the lights on"? What if I am trying to find out in a complex peere to peer environment whi is initiating the interaction? "When one door closes, another opens; but we often look so long and so regretfully upon the closed door that we do not see the one which has opened for us." -- Alexander Graham Bell Toby Considine Chair, OASIS oBIX TC Facilities Technology Office University of North Carolina Chapel Hill, NC Email: Toby.Considine@ unc.edu Phone: (919)962-9073 http://www.oasis-open.org blog: www.NewDaedalus.com -----Original Message----- From: Aaron Hansen [mailto:a.hansen@controlco.com] Sent: Tuesday, October 02, 2007 1:24 AM To: obix-xml@lists.oasis-open.org Subject: Re: [obix-xml] oBIX 1.1 Issues 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. >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]