RE: [cam] Suggestion to reduce complexity

["David RR Webber \(XML\)" <david@drrw.info>]

Martin,

 

Many thanks for summarizing the changes in jCAM we have been working on.

 

I'd like to highlight the super opportunity this is opening up for our team.  When we began to investigate DROOLS and other scripted components - it became clear that we can do more with less specification.

 

In other words - what communities like DROOLS need is our XML toolset, while providing an open framework to integrate through.  Conversely - we do not need to provide extend catchall tools - rather a descreet toolset that expects people to use powerful tools like DROOLS when their needs require it.  And the jCAM toolset provides a rapid means for people to leverage what we have learned over the past three years and deploy to their own environments.

 

I believe we are now close to seeing that light at the other end of the tunnel.

 

Similarly the <ExternalMapping> requires a pluggable approach - so that people can build to their local needs while quickly taking advantage of what CAM offers.

 

Right now we have two parts to that mapping puzzle - one is the XSLT approach and saxon processor - and the other is a SQL database persistence tool we developed here at NIH - and both solve the multiple parent/child heirarchy issues in different ways. 

 

This covers a wide range of needs for people - outputting to XML or HTML targets, or outputting to JDBC / SQL.  This is obviously not a 100% solution - but rather something that gives a 80:20 approach that they can extend and enhance as they need.  (As Martin notes - this really never can be - given the specialized complex needs of typical backend applications).

 

So - back to the work at hand.  I like the idea of re-factoring our specification and rationalizing it to be a simple core that supports a pluggable framework.  Consolidating the core functionality into sections A and B of the templates.  We have learned much over the past 18 months to facilitate this based on practical templates built.

 

We will need to schedule this editing work as responding to comments around our committee draft - and producing a revised committee draft for review.  (Team - please feel free to add more comments here too!).

 

I also want to schedule some regular conference calls to coordinate work on this starting early in March - so people can begin planning to support that effort in a couple of weeks time.

 

Once again - thanks to Martin for the hard work in building and investigate and testing out these techniques thru the jCAM toolset.

 

Thanks, DW

-------- Original Message --------
Subject: [cam] Suggestion to reduce complexity
From: martin.me.roberts@bt.com
Date: Mon, February 13, 2006 12:13 pm
To: <cam@lists.oasis-open.org>

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

British Telecommunications plc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no. 1800000
This electronic message contains information from British Telecommunications plc which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately.