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

 


Help: OASIS Mailing Lists Help | MarkMail Help

cam message

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


Subject: Suggestion to reduce complexity


Dear all,
  over the last few weeks I have been revising JCam to be a more modular piece of software.  In the process I have been moving into the area of the DataValidations section of the specification.
 
  I essence this means that JCam now has some implementation that sort of does every section within the CAM Committee Draft 1.0.  However, non of the implementations of the latter sections C,D,and E are really satisfactory against the CAM spec.  Why?  this has to do with two things 1) the CAM spec is not very clear in these areas, 2) some dependencies exist to make the sections work.
 
For Section C the registry interface there is a need for a standard Noun specification that would enable an abstract registry interface to work.
 
For Section D the DataValidations section there is a desire to see script based validations and also the CAM simple conditions.  However, in implementing the Script interfaces it has become clear that the spec needs to include something about return values, handling of errors and potentially the order of precedence of the validations.  This is not trivial.
 
For Section E the ExternalMappings the CAM spec is woefully oversimplified.  I would go as far as saying it is almost unimplementable and even if it was I woudl question why we would do it in the fashion the spec says.  I know this sounds rather harse, but I have tried to implement it and some things prove almost impossible such as handling repeated sections and actual transformation of values.  Again JCam has got round this by implementing a pluggable framework that currently supports XSLT 1.0 but it could support any other suitable transform.
 
What this comment leads me to feel is that we need to cut the 1.0 specification down to simply supporting the first two sections of the CAM Template i.e. Assembly Structure and BusinessRulesContext.  These are strainght forward and provide a suitable validation engine that is powerful and should go someway to helping XML handling.  Section C,D,and E can then remain part of CAM as non-normative extensions that would not be refered to in the 1.0 specification but would be published as small documents that would be planned for inclusion into the 1.x releases of the specification.
 
The result - a standard for CAM.  yet a clear roadmap for future extensions and enhancements.  The CAM users and developers could express or even vote for what they would like to be done next.
 
  I believe this is a pragmatic and sensible proposal to get CAM standardised and enable it to be used and understood.
 

Martin Roberts
Group Research
e-mail: martin.me.roberts@bt.com
tel: +44(0) 1473 609785  clickdial <http://clickdial.bt.co.uk/clickdial?001609785.cld>
fax: +44(0) 1473 609834
Intranet Site :http://twiki.btlabs.bt.co.uk/twiki
pp 16 Floor 5, Orion Building, Adastral Park, Martlesham, Ipswich IP5 3RE, UK

 


 


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