[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: oBIX 1.1 Issues
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]