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


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] Content Assembly Mechanism (CAM)

Olivier and Lech,

Thanks for your questions.  Been a while since I've posted to the xml-dev list.

I think it is important firstly to determine what the role and purpose of each flavor of XML schema technology is, and hence what are the strengths and where you would want to match appropriately to what your needs are.

So if I'm looking at XSD Schema, Relax NG, Schematron, and CAM for me its pretty clear.

Bear in mind I was part of the original early work on XSD coming from DTD, and then I was on the Relax NG TC so ably led by James Clark, and that the OASIS CAM work came out of the UN/CEFACT ebXML initiative and the need for content assembly to support business information exchanges and business process automation engines.  Also Martin Roberts contributions were significant in shaping CAM templates and his direct work with Schematron, Examplotron and XPath and their principle authors.

Suffice to say - we learned a tremendous amount from all these good folks work - and the result is a blend that is focused on business information exchange needs.  So what are the differentiators here?  Let me break it down into a list.

1) CAM templates are context driven, via both rules and parameters (key to support Business Process engine integration and UN/CEFACT CCTS work)

2) CAM templates are designed to be WYSIWYG XML in plain text XML syntax that is simple to follow and do

3) Separation of template into discreet sections for structure, rules, and extensions (lookups, dictionaries, et al)

4) There are two forms of a CAM template available the .cam, and the internal .cxf format - and this second format is super friendly to xslt and Java processing - making tool development and processing very easy.

5) We adopted XPath as the rule syntax - no need to invent yet another rule language - library functions widely available for implementers.

6) CAM is designed to do dictionary based top down content assembly and design (now have this working in the 1.6.9 release of the CAM Editor toolkit) - and the discreet template sections make component assembly possible.

7) Supports naming and design rule (NDR) approaches with evaluators to check for common consistency and ability to automatically generate conformant XSD schema from a CAM template.

8) Future extensions - semantic support - ability to integrate with OASIS SET TC work on automated mapping and generation of OWL assertions directly from CAM templates (currently support automated CAM dictionary generation).

Combined together this gives CAM templates a tremendous flexibility focused specifically on making developing business information exchanges simpler, quicker with dependable interoperability.

Can CAM do everything that XSD and Relax NG does?  No - and its not intended to.  

Can it do 99.9% of what typical good interoperable business information exchanges need? Yes.

Can CAM do things that XSD + Schematron cannot do? Most certainly - it combines that into one technology.

I'm excited about the results we are now getting with the sourceforge work on the CAM Editor toolkit and particularly the uptake in the NIEM.gov community.  We've been able to demonstrate a 10x faster development cycle compared to using XSD schema alone - and now support top down (dictionary) and bottom up (ingest existing XSD schema) approaches to information exchange development.

As ever with increasing adoption there is much more work to be done, but these are good problems to have.

Certainly we need to release a new OASIS CAM specification incorporating all that we've learned and improved over the past two years - and that work has started.  Also new standards work such as OASIS SET TC and UN/CEFACT XML4CCTS provide areas where we need to align to and describe the connections for adopters.

I'd like to feel that XML developers will view CAM as another useful tool in the kit bag that can help them deliver better solutions to end users quicker and with better interoperability.  Meanwhile maintaining compatibility with their familiar tools for XSD.

We obviously welcome developers to contribute to both our OASIS standards TC work and the open source work through sourceforge.net along with writers and folks who can help show people successful applications.  

As we all know - success for technology is way more than just having good ideas and angle brackets - it takes a whole village to raise a good child.

Thanks, David Webber


On Wed, Oct 7, 2009 at 1:53 PM, Olivier Rossel <olivier.rossel@gmail.com> wrote:
> after just a few minutes of reading:
> CAM looks great to enforce subtle non-trivial validation rules in your schema.
> but defining the structure of the document directly from a sample XML
> structure sounds extremely low-level.

I have to agree and openly criticise reinventing the wheel. The IBM
article mentions building a better mousetrap, but it forgets that very
often programmers reinvent the wheel. There is a very validation
engine out there that both the thing that CAM does and it's called
Unsurprisingly, CAM uses XPath for businness rule validation, which is
exactly what RelaxNG has with Schematron rules.
Relax, especially in it's compact syntax is far more readable, in my
view, for defining structure.

> i hope some people from CAM are around so we can discuss those points.

I hope so too, I really would like to see the effort being pointed in
the right direction, such as extending one of the existing standards.
Despite my criticsm, there are some great ideas in there, such as
featuring code lists and separating business rules from defining XML
structure. Ideally I would really want to see the best of all schema
validation engines merged into one some time in the future.


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

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS