[OASIS Issue Tracker] Commented: (ENERGYINTEROP-592) Clean up inheritance and substitution in partyIDs

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ http://tools.oasis-open.org/issues/browse/ENERGYINTEROP-592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=28283#action_28283 ] 

Toby Considine commented on ENERGYINTEROP-592:
----------------------------------------------

This is a new issue. Previously, partyID was abstract and all instances of PartyID named, c.f., enrolleePartyId, registreePartyID, etc. 

In this WD, we have moved agressively to adopt the Party/CounterParty terminology for transactive services with the resulting use of partyID, counterPartyID in numerous payloads.THis broke our ability to have a non-specific "partyID" in payloads (which was quite useful) as well as the ability to distinguish between a single instance of, say, counterPartyID and partyID.

Two paths are visible:

1) generic abstract version becomes "Actor", with the abstract "actorID" being used for all type-safe generic references. PartyID would then be demoted to stand alongside the other ActorID-derived types. THis would require re-writing the beginning of section 5.

2) make partyID abstract again, and use another terminology for pairs in Transactive messages, i.e., partyID and countnerPartyID. This causes problems in the type party whis currently concrete but would then have an abstract ID which would require substitution in any communication. That *might* be a good thing.

Whenever this is done, several payloads would require review to make sure their cardinality is correct.

> Clean up inheritance and substitution in partyIDs
> -------------------------------------------------
>
>                 Key: ENERGYINTEROP-592
>                 URL: http://tools.oasis-open.org/issues/browse/ENERGYINTEROP-592
>             Project: OASIS Energy Interoperation TC
>          Issue Type: Bug
>    Affects Versions: wd32
>         Environment: Toby Considine
>            Reporter: Toby Considine
>            Assignee: Toby Considine
>             Fix For: WD33
>
>
> In current schema, all PartyIDs are derived from PartyID (implicitly through substitution group). PartyID itself was previously abstract, and now is concrete. THis periodically causes processing errors, particuarly when MinOccurs is allowed. For example:
> For example, the type EiTarget includes (abreviated)
> 		<xs:sequence>
> 			<xs:element ref="eitc:venID" minOccurs="0" maxOccurs="unbounded"/>
> 			<xs:element ref="eitc:partyID" minOccurs="0" maxOccurs="unbounded"/>
> 		</xs:sequence>
> As currently defined a venID is a PartyID, so the processor may be unable to determine whether a listed venID is one of the unbounded venIDs or the first of the unbounded partyIDs. THis only occurs because of the indeterminacy of the count of venID above. there would be no problem if, for example, venID was specified as minOccurs="1" maxOccurs="1"

-- 
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