RE: [obix-xml] oBIX 1.1 Issues

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

Well that seems like a nice feature.

I don't think Freebusy can tell anyone anything about the busy times.
However, it can specify a url if the entity has a public (freebusy)
calendar.  I can't get my head around whether that is something for oBIX or
is one of those standards that a product is responsible for bringing
together.



-----Original Message-----
From: Considine, Toby (Campus Services IT) [mailto:Toby.Considine@unc.edu] 
Sent: Tuesday, October 02, 2007 3:53 AM
To: 'Aaron Hansen'; obix-xml@lists.oasis-open.org
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.
>