Re: [ws-calendar] Please review PIM WD03 - specific questions and requests for corrections

[Mike Douglass <douglm@rpi.edu>]

Notes so far:


Line 27: Replace reference to draft XML spec for ical with ref to RFC6321
http://tools.ietf.org/html/rfc6321

Line 38: Update with rf to http://tools.ietf.org/html/draft-daboo-calendar-availability-03 - editors changed to C. Daboo, M. Douglass

Line 87: Table 1.1 A gluon is influences the serialization -> A gluon influences the serialization  (extra "is")

LIne 93: Table 1.2: "Busy often overlays is overlaid by Availability. "  ??


Line 319: Figure 6.
The XML spec says something along the lines:
A tolerance property value is a set of durationValueTypes.

A durationValueType is just a restricted set of characters to represent an ISO8601 duration e.g. PT10M

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.

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)
(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?
(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

--
William Cox
Email: wtcox@CoxSoftwareArchitects.com
Web: http://www.CoxSoftwareArchitects.com
+1 862 485 3696 mobile
+1 908 277 3460 fax

---

Spam
Not spam
Forget previous vote

-- 

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