The PartyRef accepts refer any kind of object

Bug #700136 reported by Diego Manhães Pinheiro
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OSHIPpy
Fix Released
Medium
Diego Manhães Pinheiro

Bug Description

The PartyRef must accept only refer objects which are considered parties in a demographic or identity service. Into the range of possibilities there are : PARTY, PERSON,ORGANISATION, ACTOR, GROUP,ROLE and AGENT objects.
Abstract supertypes are also allowed if the referenced object is of a type not known by the current implementation of this class (in other words, if the demographic model is changed by the addition of a new PARTY or ACTOR subtypes, valid PARTY_REFs can still be constructed to them). Peharps object Introspection is the only way no fix it.

Changed in oship:
milestone: none → 1.5
importance: Undecided → Medium
Revision history for this message
Tim Cook (timothywayne-cook) wrote : Re: [Bug 700136] Re: The PartyRef accepts refer any kind of object

On Wed, 2011-01-12 at 00:40 +0000, Launchpad Bug Tracker wrote:
> Title:
> The PartyRef accepts refer any kind of object
>
> Status in Open Source Health Information Platform (OSHIP):
> New
>
> Bug description:
> The PartyRef must accept only refer objects which are considered
> parties in a demographic or identity service. Into the range of
> possibilities there are : PARTY, PERSON,ORGANISATION, ACTOR,
> GROUP,ROLE and AGENT objects.
> Abstract supertypes are also allowed if the referenced object is of
> a type not known by the current implementation of this class (in other
> words, if the demographic model is changed by the addition of a new
> PARTY or ACTOR subtypes, valid PARTY_REFs can still be constructed to
> them). Peharps object Introspection is the only way no fix it.

No.

Just be sure that all subtypes "provides" the IParty interface.

--Tim

--
***************************************************************
Timothy Cook, MSc
Project Lead - Multi-Level Healthcare Information Modeling
http://www.mlhim.org

LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook
Skype ID == timothy.cook
Academic.Edu Profile: http://uff.academia.edu/TimothyCook

You may get my Public GPG key from popular keyservers or
from this link http://timothywayne.cook.googlepages.com/home

Changed in oship:
assignee: nobody → Diego Manhães Pinheiro (dmpinheiro)
status: New → Fix Released
Revision history for this message
Diego Manhães Pinheiro (dmpinheiro) wrote :

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Em 11/01/11 23:41, Tim Cook escreveu:
> On Wed, 2011-01-12 at 00:40 +0000, Launchpad Bug Tracker wrote:
>> Title:
>> The PartyRef accepts refer any kind of object
>>
>> Status in Open Source Health Information Platform (OSHIP):
>> New
>>
>> Bug description:
>> The PartyRef must accept only refer objects which are considered
>> parties in a demographic or identity service. Into the range of
>> possibilities there are : PARTY, PERSON,ORGANISATION, ACTOR,
>> GROUP,ROLE and AGENT objects.
>> Abstract supertypes are also allowed if the referenced object is of
>> a type not known by the current implementation of this class (in other
>> words, if the demographic model is changed by the addition of a new
>> PARTY or ACTOR subtypes, valid PARTY_REFs can still be constructed to
>> them). Peharps object Introspection is the only way no fix it.
>
> No.
>
>
> Just be sure that all subtypes "provides" the IParty interface.
If we follow this approach, a circular import problem will be created:
The demographic module depends on identification module. That's why I
said the only way that I could imagine fix it is using object introspection.
In my opinion, the only expected design by the openEHR specs is pass all
PartyRef composite objects on the constructor method. I just include a
alternate construction mechansim because makes more sense to me pass the
referred object itself and retrieve the data from it, especially if you
want validate the object.
>
> --Tim
>
>
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (Darwin)

iQEcBAEBAgAGBQJNLaOeAAoJEEfarWn4YOc8EUUH/1/S0kGyX2nMM+g/YlcqY2Ih
rnYJ/Ti4zt/xqrnqXhynyVwDYPg4OQGGM3T6igIH7OBFqr1tEgl7eZXis+BRz2Sh
HGR5Dfzel8FtsehumWasBP0LJhK6G5mgO81DNXTFmHHwxrLYvAQDRVvIc381T63n
gpGWG9/QaDfzIguGPvatsPGZyZRbALAfSWmWHtqs4Q4U+p5ukIVAcrsnF0685nVh
FG+5uy25xMCowXx9KNVNTnq0+WftReok43JTEZiH22J8yNH5tGw5idKKsOjNpmdE
oeL7wYcpFCvoUI6dqWraTWwXL1/i469A3SBxyw8dSnnfQ99uyoUNtmtkyiiTzCs=
=ROjp
-----END PGP SIGNATURE-----

affects: oship → oshippy
Changed in oshippy:
milestone: 1.5 → none
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.