OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebsoa message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [ebsoa] RE: [ebxml-dev] ebXML core components derivation by restriction


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.l.schuldt@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?
> 
> Ron Schuldt
> Senior Staff Systems Architect
> Lockheed Martin Enterprise Information Systems
> 11757 W. Ken Caryl Ave.
> #F521 Mail Point DC5694
> Littleton, CO 80127
> 303-977-1414
> ron.l.schuldt@lmco.com
>  
> 
> 
> 
> 
> 
> 
> 


http://drrw.net


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]