Re: [cml/ccml-discuss] Upgrade path from Jumbo 5.4.2 to CMLXOM 2.5

[Dr P. Murray-R. <pm...@ca...>]

On Nov 9 2008, Egon Willighagen wrote:

>On Sat, Nov 8, 2008 at 11:59 PM, Peter Murray-Rust <pm...@ca...> wrote:
[...]
>>
>>> 4. CMLBond.addBondType(CMLBondType)
>>
>> CML.appendChild((CMLBondType) element)
>
>I considered that... but won't this give validation problems? that is,
>isn't the (allowed) hierarchy defined by the schema, which CMLXOM
>would follow?

We have moved (through Joe's work) to RelaxNG and a Schematron approach. 
The XSD was giving us very little that was useful and was very heavy. The 
new method has a later binding in effect - rather than compiler checking it 
is runtime checking.

Whether you want to check is up to you. You are always still dealing with 
CMLElements so the surprises are limited. Let's say you write:

>> CML.appendChild((CMLBondType) element)
instead of 
>> CML.appendChild((CMLBond) element)

I would expect you would find this error fairly soon as the output would be 
semantically wrong. We can also check at runtime by something like:

CML.appendChild(CMLElement child) {
 ... if (this.hasAllowedChild(child)) { // where hasAllowedChild class a 
schematron-like routine (we currently base this on this.query().

>
>Actually, now that I ask, I think I remember you saying that much
>hierarchy was removed from the schema... in favor of have 'any'
>content... What is the favored way for CML validation now? I did note
>some RelaxNG in the jar... Is there convenient Java code to validate
>according to the new CMLXOM specs files?

The constraints are experessed as schematron and this is simply XSLT. I am 
not sure whether we have released it - I don't think it's at SF yet. I have 
also turned some of this into query() but this is early.

Do you rely much on validation? Examples would be very useful. I think the 
most likely is that it would be linked to a convention.

P.

>
>>> I'd really like to have CDK 1.2.0 (scheduled for this month) based on
>>> CMLXOM, so that we get done with that circular dependency when
>>> depending on Jumbo...
>>>
>>> Please advice about the replacement constructs for the above API 
>>> changes.
>>
>> I'll give this top priority if you have any more
>
>I'll use the above constructs and run the tests...
>
>Egon
>
>

-- 
Peter Murray-Rust
Unilever Centre for Molecular Informatics
Chemistry Department, Cambridge University
Lensfield Road, CAMBRIDGE, CB2 1EW, UK
Tel: +44-1223-763069 Fax: +44 1223 763076