Re: [Cdk-devel] [ cdk-Bugs-639455 ] CML bonder orders have wrong format

[E.L. W. <eg...@sc...>]

On Saturday 23 November 2002 14:45, Peter Murray-Rust wrote:
> >The current reader only parses CML1. The 1,S,2,D,3,T is part
> >of CML2. (right?)
>
> CML V1.0 implicitly defined the convention 1,S,2,D,3,T  but did not
> deliberately mandate it. The paper encouraged the use of the above
> convention but made it clear that other conventions were allowable (e.g.
> some systems have bond orders of 4, -5, etc.) 

It has been some time that I actually read the article... most of the times, I 
check the DTD... i.e. the explicit definition... but, I understand that, DTD 
is too limited to allow 1,S,etc... Ok, bug accepted ;)

> All the CML writers that I
> have encountered other than CDK have adopted the 1,S,2,D,3,T convention.
> This means that all CML files except those from CDK are interoperable.

Ok. CDK will be no different then... 

> If CDK wishes to have its own convention for bond orders it is welcome to
> do so, but they should be labelled as such. So you could write
> <string builtin="order" convention="CDK">1.5</string>
> and this would be acceptable. However you would need a CMLReader that
> understood CDK bond order conventions to read this and you would have to
> convince the other software writers that this was useful.
>
> The CML convention was designed to be extensible so that if you wished to
> have a bond order of (say) 2.5 you could write:
> <string builtin="order" >A</string>
> <...>
> <string builtin="order" convention="CDK">2.5</string>

The CDK output will preferable not use any non default convention. That's the 
idea... if it does not, then it actually is a bug in the CML writer...

> Most CMLReaders would understand the first. I don't know what CDK would do
> with it. Note that order is a <string> and not a <float>. This is
> deliberate To understand the second they would require to implement a CDK
> convention reader. I suspect most would default to "unknown bond order".
>
> >  This will be fixed when a CML2 reader is
> >written.
>
> CML2 does not mandate a controlled vocabulary for bond orders.

Ah, then it won't .... 

> It is important that CML Readers and Writers produce valid CML and it is
> important to work for interoperability. 

Agreed. That's the whole point of CML...

> CMLWriters are easier to create
> than CMLReaders especially if they have to deal with multiple conventions.

Ah, yes... kind of you to mention that... ;) the strenght of my CML reader is 
the flexibility in reading conventions... Programs can very easily write and 
add a handler for parsing a specific convention.

Egon