atom feed18 messages in org.oasis-open.lists.ebsoaRe: [ebsoa] RE: [ebxml-dev] ebXML cor...
FromSent OnAttachments
Schuldt, Ron LJul 28, 2004 7:17 am 
David RR WebberJul 28, 2004 7:37 am 
Chiusano JosephJul 28, 2004 8:54 am 
Chiusano JosephJul 28, 2004 9:55 am 
Duane NickullJul 28, 2004 9:55 am 
Chiusano JosephJul 28, 2004 10:02 am 
Schuldt, Ron LJul 28, 2004 10:08 am 
Chiusano JosephJul 28, 2004 12:38 pm 
Schuldt, Ron LJul 28, 2004 12:41 pm 
Schuldt, Ron LJul 28, 2004 1:39 pm 
David RR WebberJul 28, 2004 1:46 pm 
Carl MattocksJul 28, 2004 2:04 pm 
Schuldt, Ron LJul 28, 2004 2:51 pm 
Schuldt, Ron LJul 29, 2004 7:11 am 
Chiusano JosephJul 29, 2004 9:31 am 
Schuldt, Ron LJul 29, 2004 3:12 pm 
Schuldt, Ron LJul 30, 2004 10:05 am 
Duane NickullJul 30, 2004 10:43 am 
Subject:Re: [ebsoa] RE: [ebxml-dev] ebXML core components derivation by restriction
From:David RR Webber (dav@drrw.info)
Date:Jul 28, 2004 1:46:27 pm
List:org.oasis-open.lists.ebsoa

Ron,

This is exactly why I was pointing at CAM.

CAM provides that ability to tie the conceptual to the specific.

You would not want to store these rules at the CCTS level - since they are highly implementation specific, subject to versioning, context and more.

However CAM provides a very neat constraint mechanism founded in XML - that does not require you to go down the OCL path.

And of course - once again - CAM is designed to mesh with CCTS and pick up these implementation mechanisms that clearly CCTS itself is not intended to do since they are neutral objects that inform the implementation layer only.

Thanks, DW =========================================================== Quoting "Schuldt, Ron L" <ron.@lmco.com>:

Fred,

<Duane>Would this not be served by an iterative process according to the CCTS methodology itself? For example, a Health Insurance Policy Contract is a specialized (in context(s)) instance of the type Contract, in itself a specialization of "Agreement". Through iterative revision, the high level "contract" should have a notion of "type" with an enumerated list. The enumerated list may be conditionally validated [1] against other qualifiers (something that XML schema cannot currently do) and "Health Insurance Policy" is merely a type of contract.</Duane>

<Fred>I agree with the mechanism, but CCTS does not support it. Enumeration is only supported at the lowest level, for data types, not for aggregates. Conditions can be stored in the "usage rule" of a CC/BIE, but that is free text for the moment. I would be in favour of defining an OCL profile/subset for such rules, that also would be 1:1 translatable to XMLPath.</Fred>

If you agree with the mechanism and CCTS does not currently support it, is there any reason that CCTS could not be changed and support it in the future?

http://drrw.net