Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mdht-dev] OCL Cardinality

David -
	In order to report that a conformance requirement is not met, we need a scenario that fails.  In order to accomplish this, we imply a lower bound of 1 for all constraints
This was the issue which triggered this update - we were checking for size >=0 and size <=1 which would not fail 

	This is a bit of a CDAism because of the levels of constraints (SHALL,SHOULD, and MAY)  
SHALL is required to have a lower bound 1 while SHOULD and MAY have a lower bound 0 within the publication


l will look to add such an explanation to the matrix

thanks

Sean

	


On Jan 31, 2016, at 10:11 PM, David Cai <David.Cai@xxxxxxxxxxxx> wrote:

> Hi Sean,
> 
> Just on the Strict Base property cardinality 0..1, and property redefinition 0..1, why is the OCL size=1? That doesn't  allow size=0, does it?
> 
> -----Original Message-----
> From: mdht-dev-bounces@xxxxxxxxxxx [mailto:mdht-dev-bounces@xxxxxxxxxxx] On Behalf Of sean.muir@xxxxxxxxxxxxxxx
> Sent: Saturday, 30 January 2016 8:13 AM
> To: mdht developer discussions <mdht-dev@xxxxxxxxxxx>
> Subject: [mdht-dev] OCL Cardinality
> 
> 
> Per our discussion yesterday - i created a CDA cardinality map
> 
> let me know if there are any questions
> 
> i will look to put this on our eclipse site - as soon as i figure out where
> 
> thanks
> 
> Sean
> 
> 
> 
> The information contained in this e-mail message and any accompanying files is or may be privileged or confidential. If you are not the intended recipient, any use, dissemination, reliance, forwarding, printing or copying of this e-mail or any attached files is unauthorised. This e-mail and any attachments may be subject to copyright. Copyright material should not be reproduced, adapted or communicated without the written consent of the copyright owner. If you have received this e-mail in error please advise the sender immediately by return e-mail or telephone and delete all copies. NEHTA does not make any representations or give any guarantees in respect of the accuracy or completeness of any information contained in this e-mail or attached files. Internet communications are not secure, therefore NEHTA does not accept any liability for the contents of this message or attached files.
> _______________________________________________
> mdht-dev mailing list
> mdht-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/mdht-dev

Attachment: smime.p7s
Description: S/MIME cryptographic signature


Back to the top