1)
Agree that XCAL should trump ICAL, to the extent it does. Have
they finished, yet?
2)
If we are going to do all this time stuff, it means that oBIX servers
should be able to talk to NTP servers. Not part of oBIX, but implied by the
spec.
3)
If we ever get a federated identity model laid atop some future
security model, (2) will be required (to create a common understanding of token
aging)
4)
Are we defining a name for scheduled events? If I go to an oBIX
server and ask “What’s on the schedule”, I will probably want
to find who scheduled it.
5)
A future version will want some accounting/billing/BPEL section
alongside the iCAL. This may be no more than an <additional info> that
that holds as-yet-undefined XMP payload</additional info>
"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
|
From: Brian Frank
[mailto:bfrank@tridium.com]
Sent: Monday, October 01, 2007 5:17 PM
To: Jeremy Roberts; obix-xml@lists.oasis-open.org
Subject: RE: [obix-xml] oBIX 1.1 Issues
Although it
gives me the shivers to think of implementation - I agree that we probably need
floating times considering Dave's use case. So thats a bummer - a lot of
extra complexity.
Is there any consensus on shortening weekday and month then? I here 2 votes
(me and Dave) for it.
Jeremy: xCal doesn't specify too much - it pretty much just leaves everything
in its iCalendar string encodings for property parameters and values. Are
you suggesting that? Because I think we want to use XML and oBIX to pull the
property parameter and value structure out into contracts and typed values (I
think this is what Dave was suggesting too).
Brian
-----Original Message-----
From: Jeremy Roberts [mailto:jeremy@lonmark.org]
Sent: Mon 01-Oct-07 4:34 PM
To: obix-xml@lists.oasis-open.org
Subject: RE: [obix-xml] oBIX 1.1 Issues
I felt similarly on these items as Dave has expressed. Therefore, I've
copied Dave's comments (thanks Dave) and changed only a few:
1) Not sure, says Dave. Jeremy says: it's only important if we break
backward compatibility (like with item 6's day/month names).
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, says Dave. Jeremy says: follow iCal instead of any other
specification, except if xCal differs from that. We should follow xCal
(the official XML representation of iCal) anytime it differs from iCal (though
I do not imagine that it does but would need to check that).
7) Jeremy says he does not understand enough of this to make a recommendation.
8) Are multiple RRULE's necessary for us? Yes, it's legal in iCalendar,
but what is the value?, says Dave. Jeremy says: I am open on this.
9) I'd say no. VFREEBUSY might be useful, but not enough to warrant
looking at it right now.
Cheers,
Jeremy J. ROBERTS, Technical Director
LONMARK International - http://www.lonmark.org/
<http://www.lonmark.org/>
Technical Office - mailto:tech@lonmark.org
<mailto:tech@lonmark.org>
PO Box 268, Jamison PA 18929-0268, USA
T: +1 215 918-1026 . F: +1 215 918-1027
________________________________________________________________
________________________________
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.