1. Improvement WSCALENDAR-460
    Consider "Confidence" as a Property
  2. Improvement WSCALENDAR-411
    Support for randomized intervals is desirable in many applications. Suggest adding one or more randomization parameter types. Should be applicable to start, end, or duration.
  3. Task WSCALENDAR-337
    Collector for Schema Profiling and Simplification
  4. Improvement WSCALENDAR-336
    Collector for Schema Data issues
  5. Improvement WSCALENDAR-335
    Collector for Schema Issues
  6. Sub-task WSCALENDAR-305
    Simpler and more constrained information model in addition to the PR02 information model
  7. Bug WSCALENDAR-260
    Line 718, 1646 - are the items in the tables "parameters", "aspects" or "elements" - make consistent throughout document
  8. Sub-task WSCALENDAR-231
    Text needed on the use of xs:anyType in the schema
  9. Sub-task WSCALENDAR-230
    Need to define TOLERANCE property
  10. Sub-task WSCALENDAR-229
    Remove any unused types from the schema, probably replace with some form of annotation.
  11. Sub-task WSCALENDAR-228
    Case of gluon type wrong
  12. Sub-task WSCALENDAR-227
    define the "components" and "properties" elements at the top level
  13. Sub-task WSCALENDAR-226
    Schema is wrong around duration.
  14. Sub-task WSCALENDAR-225
    The availability extension was not imported.
  15. Sub-task WSCALENDAR-224
    Ws-Calendar looks to be a terrific advance for the smart grid and providing ways for users to use only what they need without having to understand all of Ws-Calendar.
  16. Improvement WSCALENDAR-223
    All uses of granularity are not clear
  17. Sub-task WSCALENDAR-222
    Recurrence Rules seem recursive, Unable to build VAvailability
  18. Sub-task WSCALENDAR-221
    Mispelled element in Performance Characteristics
  19. Sub-task WSCALENDAR-220
    Schema Error in RecurType
  20. Sub-task WSCALENDAR-217
    Define performance property
  21. Sub-task WSCALENDAR-210
    Line 287 - Did not check examples for well formedness.
  22. Bug WSCALENDAR-206
    CLONE -All - ALL fields should be distinctly listed as mandatory or optional. Some are specifically noted and some are not.
  23. Task WSCALENDAR-202
    Schema-related work
  24. Improvement WSCALENDAR-199
    All - Should the xml file scripts be limited to a certain number of characters such that the file could be sent via SMS text messaging or possibly via the radio data service (RDS) broadcast service.
  25. Improvement WSCALENDAR-198
    All - Given the different context with which a timing mechanism can be used, for which contexts does this proposed standard apply?  E.g. dispatch, settlements, operations characteristics, scheduling tags, bilateral schedules... 
  26. Sub-task WSCALENDAR-197
    All - ALL fields should be distinctly listed as mandatory or optional. Some are specifically noted and some are not.
  27. Improvement WSCALENDAR-196
    All - Examples used in the document are not relevant to subject (class schedules) which increases risk of overlooking relevant issues that are involved with power and energy timing.
  28. Sub-task WSCALENDAR-195
    Line 1426 - Does this mean that derived standards like EMIX and EnergyInterop will also be Restful?
  29. Improvement WSCALENDAR-193
    Line 692 - While physics is an interesting subject, this is not a PBS show and talking about gluons and quarks sounds neat, but is a distraction. If the term gluon needs to stay fine, but there might be better terms.
  30. Sub-task WSCALENDAR-192
    Line 38 - No problem with WS-Calendar adopting semantics and vocabulary from iCalendar, but it sounds like the standard will only use iCalendar in applicable web service contracts.
  31. Improvement WSCALENDAR-187
    Line 861 - Last line under "Performance" two periods ".." Should be one.
  32. Sub-task WSCALENDAR-186
    Line 857 - Are inheritance rules defined for the sequence or service level ? Are they message specific or service specific. If message specific, which system enforces the specs ?
  33. Sub-task WSCALENDAR-182
    Line 287 - Did not check examples for well formedness.
  34. Improvement WSCALENDAR-181
    Line 206 - Standard schema should include a WS Specification as an appendix to this document, akin to an XML Data Dictionary.
  35. Improvement WSCALENDAR-180
    Line 183 - "UCT vs. Local Time" Should it be "UTC" ? For Universal Coordinated Time
  36. Bug WSCALENDAR-179
    Line 135 - The framework as it stands define the services execution context. The RTO can't endorse unless and until the policy context is defined. When and would the policy context be defined ?
  37. Improvement WSCALENDAR-178
    Line 41 - "Normative" reference intent. Is interpreted to mean Standards forming ? If so what are the business processes affected and performance benchmarks for compliance ?
  38. Bug WSCALENDAR-177
    Lines 3 and 8 - The architecture as outlined may not offer a central system to control, monitor and audit events and transactions.
  39. Improvement WSCALENDAR-175
    Line 1476 - "principals" to "principal's"
  40. Sub-task WSCALENDAR-174
    Line 861 - "A Interval or Calendar Gluon inherits its attributes through it's the closest parent" to "An Interval or Calendar Gluon inherits its attributes through its closest parent."
  41. Improvement WSCALENDAR-170
    Line 366 - Agree with Sean's comment - how is this structured? Or is it explicitly unnecessary?
  42. Improvement WSCALENDAR-169
    Line 274 - Should be 3.2.1
  43. Improvement WSCALENDAR-167
    Line 173 - Repeated text ("quite different")
  44. Sub-task WSCALENDAR-163
    Line 859 - There is no way to define an interval and then use it in a schedule without redefining it again?
  45. Sub-task WSCALENDAR-157
    Line 538 - As three optional elements there is no way to validate that one of them is populated.
  46. Improvement WSCALENDAR-155
    Line 504 - precision not accuracy. Is it one hour or 1:00:00.00 hours.
  47. Sub-task WSCALENDAR-154
    Line 440 - Not having a separate entity for a scheduled sequence makes validation difficult. E.g. is the data intended to be a sequence or a scheduled sequence.
  48. Improvement WSCALENDAR-146
    Line 1836 - Why does the example return an icalendar tag rather then a wscalendar tag?
  49. Improvement WSCALENDAR-145
    Line 1419 - Could use description of what is intended by Abstract model as different from Implementation model and how they should be considered.
  50. Sub-task WSCALENDAR-144
    Line 1423 - Schema says that wscalendarrelation is a member of properties of vtodo. UML model implies it is a specialization of VToDo. Suggest that the UML models and schema be made consistent representations.
  51. Bug WSCALENDAR-143
    Inheritance model - Inheritance model appears similar to CSS in that once defined, a term persists until overriden by a contained element. If this is so, a reference to this might make sense.
  52. Sub-task WSCALENDAR-142
    Line 579 - Why is performance a property of attach, rather then a property of interval/gluon?
  53. Sub-task WSCALENDAR-141
    WS-Calendard.xsd - Schema has error in declaration
  54. Bug WSCALENDAR-140
    Line 690 - Why do you need a separate class / tag for Gluon? Gluons seem to have an almost identical property set to Intervals. Consider merging "gluon" differences into WS-Calendar interval class.
  55. Improvement WSCALENDAR-139
    Line 142, 221 - Is this draft xCal? Couldn't find [XCAL] in the references. Note: there are several other reference inconsistencies that should be remedied.
  56. Bug WSCALENDAR-138
    Lines 199 - 202 - Recommend making standard require only universal time in messaging. Local time can always be computed "locally" allowing for one time conversion when needed. This avoids a lot of complexity in interpreting time.
  57. Improvement WSCALENDAR-131
    Line 240 - Remove the text "of the" from this line.
  58. Improvement WSCALENDAR-128
    Lines 17 and 18 - Add trademark indications to the identified standards.
  59. Bug WSCALENDAR-127
    The use of iCalendar to schedule device services across a large domain of buildings (or equipment within a building) could have the unintended effect of load synchronization.
Refresh results