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


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: [xml-dev] Are people really using Identity constraints specified in

[ Lists Home | Date Index | Thread Index ]
  • To: xml-dev@lists.xml.org
  • Subject: RE: [xml-dev] Are people really using Identity constraints specified in XML schema?
  • From: w3c@drrw.info
  • Date: Wed, 18 Aug 2004 16:54:49 -0400
  • User-agent: Internet Messaging Program (IMP) 3.2.2 / FreeBSD-4.8


Once again good observations.

Some history - CAM does indeed share some ancestry with Schematron.

British Telecomm initially attempted to use Schematron with mixed results. 
There are specific referential rules that simply will not work in Schematron.

So CAM really extends the schematron work - and combines it with the original
work from UN/CEFACT on core components and use of a semantic registry to
provide vocabularies of components - and then into a content assembly mechanism
for ebusiness transactions.

CAM itself really has been built in layers - so you can use as little or as
as you need.  Also the Level mechanism in the specification allows you to
control how many features you buy into too.

This is what we learned from the ebXML work - that people need a graduated
on-ramp - to allow interoperablity to be developed in a systematic way.

That said - I have manually converted Schematron rule sets to CAM - I did some
of the IV&I BODs that OAGi setup.  What this showed is that typically CAM
templates are 25% of the size of Schematron rules.  This is because CAM does a
lot implicitly that Schematron forces you to state.  So it ends up being much
simpler to do an initial set of CAM rules for a template.  Also - CAM is a
superset - so it has many features for which there is no equivalence in
schematron.  This is to be expected - as BT asked for those - so they could
meet their production needs - with things that were missing in Schematron.

So - the "alpha" jCAM processor basically covers off Level 1 compliance in the
specification - since BT wrote that implementation.  This is a very powerful
feature set none-the-less!  Already way more than Schematron.  Of course there
are really nice features in Level 2 and Level 3 of CAM that have not been added
yet. Those will of course be driven by project needs once again.

Over and above all this - even if you never run a single CAM template in jCAM -
you will find that capturing CAM templates of your schemas will dramatically
improve the resolution of business semantics you have in XML form that
documents what that schema is really doing.  And in a format that is extremely
human readable and verifiable, or pretty printable as needed.

The XML syntax of CAM was built so humans can read and type it - and that
business analysts that are XML literate can work with it directly.

Enjoy, DW
bry@itnisk.com writes:

> To: Hunsberger, Peter
> > 
> > Many thanks for the link, when I first head of CAM the description 
> > didn't make it sound at all useful (seems to me the name only 
> > partially reflects the intended capabilities). This might be a 
> > standard that we may eventually want to support.
> Well I don't know anything about patents, unless it were the 
> glory days of patent medicine, the things that made me think 
> about CAM was in the context of content assembly where the 
> content is not in xml format, which I supposed some patents 
> from various offices might not be. When you used the 
> repository term there I immediately thought about CAM's 
> requirements for maintaining transactional integrity. 

It was Bruce Cox who was asking from a patent perspective.  I don't
think he saw CAM as being useful there, though I'm still not quite sure

We're doing development of data management systems for Clinical Trials
data.  The CAM applicability here is not so much in transactional
assembly as it is in the way CAM allows for layers of customization:
we've got 100's of open trials that change on a regular basis.  They all
feed in and out of a common database but even within a single protocol
(and a trial may have many protocols involved) there may be variations
on how a particular screen is presented and validated depending on the
> > Questions:
> > 
> > 1) Just glancing at the spec it appears to have at least 
> some overlap 
> > with Schematron for parts of it.  Anyone looked at a Schematron to
> > CAM(/subcomponent?) conversion or the converse?
> > 
> glad to hear you say this, I also felt there were some 
> schematron similarities in the constraints of xml documents 
> using xpath obviously, however schematron doesn't really have 
> any merging/assembling capabilities of inputs (meaning 
> merging/assembling towards valid outputs). Personally I would 
> really like seeing some sort of schematron/CAM interactivity, 
> mainly cause it would be more interesting I think than 
> CAM/XSD interactivity.  

Yes, CAM obviously tries to do more than Schematron which was why I put
the "subcomponent" qualification in there.  Given the layers of
validation that CAM targets Schematron seems like a natural fit.

> > 2) Any one using this for anything production like?
> According to David Webber British Telecomm is using up to 100 
> CAM templates for "checking field trouble ticket reports on a 
> daily basis" I don't know anything about field trouble 
> tickets but supposedly they are troublesome, as well as being 
> about trouble. As I understand they are using JCAM 
>http://jcam.org.uk/ which is at an alpha state, I haven't used 
> it yet, however the spec does seem reasonably clear to me and 
> probably wouldn't be too much trouble to implement. 
> > 
> > 3) Any recommended software?
> > 
> >
> I'm not sure JCAM can be considered recommended, it's alpha 
> (and I had some troubles getting it  running), David Webber 
> is as I understand it currently working on a project which 
> should see JCAM finished by November. 

Looks potentially interesting.  Also looks like something where you need
to have some person power to dedicate to both CAM development and the
regular line of  business if you're going to get anywhere.  No such luck
at the moment (sigh).



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

Copyright 2001 XML.org. This site is hosted by OASIS