OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

obix-xml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [obix-xml] oBIX 1.1 Issues

Having looked at these issues in some depth lately:


1) Not sure


2) I’d have to say yes.  Scheduling a meeting is one thing – everyone needs to show up at the same point in time.  For scheduling, however, we want to send out the value of 8:00am to all stores/facilities and have them go on at 8:00am in their local time zone.  No way to do that using UTC, offsets, or time zones unless the scheduling app knows the time zone/offset of every destination and sends a different copy of the schedule to everyone.


3) As per #2, I think the floating time has a use.


4) Yes


5) As suggested (which is no, sort of, to the question?)


6) Yes, please.


7) Yes.  The delimited strings used for values all over the RRULE are painful as well.  Turning them into oBIX lists makes for very noisy XML (lots of XML, little data), and keeping them as strings gives you type problems.  The +/- <number> which can be added to some list values doesn’t help either.


8) Are multiple RRULE’s necessary for us?  Yes, it’s legal in iCalendar, but what is the value?


9) I’d say no.  VFREEBUSY might be useful, but not enough to warrant looking at it right now.


From: Brian Frank [mailto:bfrank@tridium.com]
Sent: Monday, October 01, 2007 12:36 PM
To: obix-xml@lists.oasis-open.org
Subject: [obix-xml] 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]