[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Commented: (ENERGYINTEROP-369) Opt containsadditional elements that are not in the submitted models - need explanationon why they are there
[ http://tools.oasis-open.org/issues/browse/ENERGYINTEROP-369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=25508#action_25508 ]
Bruce Bartell commented on ENERGYINTEROP-369:
---------------------------------------------
Comments based on files in energyinterop-1-0-schema-wd23-draft1.
Assuming that the opt in/out has replaced 2 schedules with optType. This seems OK if we can define opt type.
Looks like the venIDs are stil in. Need a defintion/use or remove.
The interim solution pending a better availability schedule from ws-calendar was to use xcal:interval. The schema has emix:businessSchedule. There is no need to skip through emix to pick up a ws-calendar element or datatype. This should be either ref to wsCalenar:interval or optSchedule with type of xcal:wsCalendarIntervalType.
OK with interim solution to avoid "one more thing" for next PR. But, the interim solution with cal interval still has issues with a lot of optional ways to create the same schedule dependant on conformance rules that cannot be enforced by a schema. The multiplicity in xcal:properties is near the leaf level. i.e. To represent a series of start/end date times it would be a series of starts followed by a series of ends. Conformance for matching sets,etc. would be in the application.
The front door option would be:
<xs:complexType name="OptPeriodProperties"> (with 1.* for the element)
<xs:complexContent>
<xs:extension base="eical:ArrayOfProperties">
<xs:sequence>
<xs:element ref="xcal:duration"/> (there seems to be some preferences for dtend instead)
<xs:element ref="xcal:dtstart"/>
<xs:element ref="xcal:uid" minOccurs="0"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
Use of recurrance properties and grammer rules fromm ws-cal (or iCal or xCal, whichever) would be great, but it seems like the timelines will not agree with EI.
> Opt contains additional elements that are not in the submitted models - need explanation on why they are there
> --------------------------------------------------------------------------------------------------------------
>
> Key: ENERGYINTEROP-369
> URL: http://tools.oasis-open.org/issues/browse/ENERGYINTEROP-369
> Project: OASIS Energy Interoperation TC
> Issue Type: Bug
> Components: schema
> Affects Versions: wd22
> Environment: Bruce Bartell
> Reporter: Bruce Bartell
> Assignee: William Cox
> Priority: Minor
>
> EIOptout:contractName - what is this for?
> venID is in twice once at root and again in EIOpt as 1->*. The defintions do nto match.
> The definition in the recurring element reads like a customer account ID ("If this ProgramConstraint is associated with a specific ParticipantAccount then this is the
> identifier of the ParticipantAccount that it is associated with.)
> validDateTimes "These are the date/times during which a DR Event may be issued. If undefined then it is assumed that the DR Event may be issued at any time except as specified by the other constraints such as the black out dates and times." This looks like a program attribute.
> maxConsecutiveDaysFilter No defintion. Enumerator of Accept or Reject. Accept or reject what?
> blackOutDateTimes Redundant with optOutSchedule. I thought we were going to use this as Resourse Constraint?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]