cam message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Suggestion to reduce complexity
- From: <martin.me.roberts@bt.com>
- To: <cam@lists.oasis-open.org>
- Date: Mon, 13 Feb 2006 17:13:36 -0000
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.
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]