[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Comments on WS-Calendar-1 0-spec-wd-06.pdf
Dear colleagues, Here are my comments. First 2 general points: -
Following our discussions on
the good terms to describe what are duration, interval and period, I felt on
the Joda-Time API. They do have a very interesting description of the almost
exact concepts. See the “Key concepts” part at http://joda-time.sourceforge.net/ -
The WS-Calendar specification
refers to xCal and iCal in many places, and there is nothing to say about that.
But sometimes, we refer to both, sometimes only xCal, sometimes only to iCal,
and it can appear strange, or having a particular importance that it does not
have (just a writing artifact in general). Just as an example, starting line 305,
in the duration definition, it is said “Well-known element from iCalendar
and xCal”, but the next phrase says “Duration is an optional parameter
of xCal objects vevent and vtodo.” This may be interpreted as “The
Duration is optional in xCal, but not in iCal”. Line
305: Duration definition – The way it is written is not really a
definition, because we did not succeed in finding a fourth term explaining what
we meant. It only gives an example of a duration in iCal/xCal. Why not using
the term “time span” to define what a period is (a period of time not
anchored to a specific date and time). Time span has the advantages of being
used as is in some date and time APIs or libraries of objects (.net in
particular), and not bringing a cyclic definition with “period that is
not anchored”. Line
332 editorial – “users” à “uses” Line 338 editorial – “assembles”
à
“assembled” Line 342 Precision: The term “Tolerance”
is given as an example of this line 332, and it is called DurationPrecision line
458 – Could be homogenized. The term Granularity is used mentioning “as
defined above”, but successive editorial changes removed the granularity
definition. Accuracy: It cannot be of type xs:Duration,
but in turn could be defined as an enumerated value. How a device with an
accuracy of 1 minute could interpret a piece of information coming from another
device indicating an accuracy of 1 millisecond. If defined by an enumerated
type, one can guess that the communication partner is more or less accurate,
and act/interpret data accordingly. If defined by a duration, this is not
possible. The low accuracy device does not know what a millisecond is, but it
could know what a “1 ms class” time information is: Something too
much precise in which it could ignore part of the figures to act “at best”. In the “Attach” definition:
ws-calendar:associatedArtifact is used for the first time with a mention “defined
above”. Line 360 editorial – “provde”
à
“provide” Line 368 and 369: This statement sounds weird
to me. “From 4:00 ending at 5:00” and “One hour beginning at
4:00” are the 2 ways to expressed the strictly same anchored period of
time. They are equivalent in the mathematical sense. So how/why the services may
be quite different ? Line 382: Interval definition “An
interval specifies a single segment of time”. Any reason not to use the
same wording than line 305. Maybe I miss something: Should “single”
be interpreted as “cannot be split” or “cannot be moved to
another anchor in the time chronology” ? Line 432: Allowing opposite definitions of
relationships (PRECEDES and FOLLOWS) brings a major interop danger. One could use
the relationships with PRECEDES only and another one with FOLLOWS only to express
the same sequence, bringing possible interpretation issues. In addition this
may facilitate falling in a cyclic-redundancy trap. I think it would be safer
(but not easy) to define a consistent and complete (I hope the term is the good
one, as used in maths) set of possible relationships. For example, “FIRST”
or “LAST” is necessary, probably not both. In addition, the
interpretation algorithm could be detailed to avoid interop issues (along with
a conformance statement saying “Apply the algo yes/no”). Aren’t
these things defined in BPEL ? Line 443 to 478: Same remark on the example
including relationships. Line 519: Granularity is used and not
already defined. Line 519 – PartitionIntervals in the
table: “Array of Duration Intervals” does not sound good to me. As
a Duration is not the same thing as an Interval, what is a Duration Interval ? Line 522 Editorial: “A schedule set
is …” à “A period set is …” – “being” à “begin”
– Kind regards Benoît
LEPEUPLE Product
Manager ARC
Informatique 2
avenue de la cristallerie - 92310 SEVRES - FRANCE Tel:
+33 1 41 14 36 00 - Mobile: +33 6 87 80 20 43 Email : b.lepeuple@arcinfo.com
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]