Michael --
Notes interleaved.
Thanks!
bill
--
William Cox
Email: wtcox@CoxSoftwareArchitects.com
Web: http://www.CoxSoftwareArchitects.com
+1 862 485 3696 mobile
+1 908 277 3460 fax
On 2/15/13 1:06 PM, Mike Douglass
wrote:
Notes so far:
Line 27: Replace reference to draft XML spec for ical with ref to
RFC6321
http://tools.ietf.org/html/rfc6321
Done. New reference is
[xCal] C.
Daboo,
M Douglass, S Lees, xCal:
The XML format for iCalendar, http://tools.ietf.org/html/rfc6321,
IETF RFC 6321, August 2011
Line 38: Update with rf to http://tools.ietf.org/html/draft-daboo-calendar-availability-03
- editors changed to C. Daboo, M. Douglass
Done. New reference is
[Vavailability] C. Daboo, B. Douglass,
Calendar Availability, http://tools.ietf.org/html/draft-daboo-calendar-availability-03,
IETF Internet Draft Version 03, September 27, 2012
Line 87: Table 1.1 A gluon is influences the serialization -> A
gluon influences the serialization (extra "is")
Since this is copied from WS-Calendar 1.0 I'll enter a Jira item
there and corrected here.
LIne 93: Table 1.2: "Busy often overlays is overlaid by
Availability. " ??
Likewise on Jira for WS-Cal 1.0; new text is
Busy
often overlays Availability
Line 319:
Figure 6.
The XML spec says something along the lines:
A tolerance property value is a set of durationValueTypes.
This is at http://tools.ietf.org/html/rfc6321#section-3.6.6
and says
Description: iCalendar "DURATION" property values are represented by
the IC:duration XML element. The content of the element is the
same duration value specified by [RFC5545].
XML Definition: Appendix A # 3.3.6
Example:
<duration>P1D</duration>
A durationValueType is just a restricted set of characters to
represent an ISO8601 duration e.g. PT10M
This is what I call a "conformed string" with the restriction rules
part of the conforming.
But "duration" is also a value, isn't it? Does that distinction also
break the recursion, but with more UML and verbal footwork? I may
have confused myself with the XSD duration which is a referenceto
I've changed the ToleranceValueType attributes to have type
"duration" rather than Duration ValueType as a step.
Tolerance is added as a property to a component to determine the
appropriate tolerance on the explicit or calculated start, end and
duration.
So in the PIM I think the problem is defining DurationValueType as
a structure with howLong and tolerance.
Good description, and seems to avoid the recursive definition. I
don't know that it'll be adjusted in WD04, as I'm trying to complete
a pass on all other text especially the highlighted.
Availability - start/end rules. - need to get back on these
On 02/01/2013 12:36 PM, William Cox
wrote:
I posted WD03 of the WS-Calendar PIM last night. PDF public link
is https://www.oasis-open.org/committees/download.php/48102/ws-calendar-pim-v1.0-wd03.pdf
; DOCX public link (for your detailed suggestions and
corrections :-) is https://www.oasis-open.org/committees/download.php/48101/ws-calendar-pim-v1.0-wd03.docx
.
There are a number of areas that can use improvement as we head
toward public review. References are to line and page numbers in
the PDF at the URI above.
In summary they are:
(1) Ensure that only necessary components are in the model
(2) Align model component names to those in WS-Calendar
(3) Ensure that there's a clear naming convention (see Setion
1.5, line 46)
(4) Eliminate remaining XSD influences (e.g. "anyURI" in
LinkType - see lines 276-283)
(5) Write more clearly on the nature of WS-Calendar wrt
parameters, properties, and value types (Section 5 line 350ff)
(6) Clarify the unbound state and how that reflects in the UML
model (see e.g. section 2.6 and 3.6.1)
(7) Consider ToleranceValueType and the apparent circularity
with respect to DurationValueType (section 3.9)
Some discussion above; not resolved.
(8) Availability and Vavailability -- what is
needed in the PIM? Should this be deferred until completion of
Vavailability so that the abstraction doesn't need to change?
Suggestions?
Pending responses from the TC.
(9) Conformance (Section 6 line 363ff): the changes
aren't visible, but are minor and the same as the previous
draft.
(10) Thoughts on other elements of Intervals, line 452ff - not
sure how relevant these conformance requirements are; partitions
seem to be moving toward a streams representation in part, and
the other elements (Description, Summary, Priority) aren't in
the PIM. Should they be?
(11) Improved text for section 3.4 (line 188ff) on primitive
types. Are the references and description right?
(12) Comments on all other YELLOW highlighted text
Of course, any other suggestions to improve clarity, focus, and
usability are welcome.
Thanks!
bill
--
Mike Douglass douglm@rpi.edu
Senior Systems Programmer
Communication & Collaboration Technologies 518 276 6780(voice) 2809
(fax)
Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180
|