[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [obix-xml] oBIX 1.1 Issues
|
Comments below Rob Zivney: any other comments on scheduled alarms from Security
system perspective? tc "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
From: Brian Frank
[mailto:bfrank@tridium.com] 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. I hate it when I get a floating time from someone in another
time zone. I suspect that it is only there for backward compatibility in ICAL 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. Sounds right – like your proposal. Thinking ahead, would
geotagging be a core unit in a futre map-ready oBIX? 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. Standard is Good - yes 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. Agree 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). Better to break early than late – especially as this is
simple enough [for now] for something to support both formats – and then
go with ICAL going forward. 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. VFREEBUSY – If we had several generators, each of which
might be called in to support an event, would we want to see if they had
already been requested in support of something else? What if we had HVAC with
one chiller and 5 zones. Would we want to know if 3 out of five were already
scheduled, so capacity would be minimal? What if there is some odd behavior
scheduled for each afternoon at 3:30…would I want to know who scheduled
it and why… All examples are a little tenuous, but I don’t think we
should just right this off… VJOURNAL – Configuration notes left by Integrator? VALARM – is this the same as checking the electric meter
at the end of the day? Does it support oBIX to oBIX systems that send each
other alarms (as opposed to control interactions) as well as letting someone
else set up the [fire alarm] as a scheduled VALARM? VTODO, even I am reaching on. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]