[gmx-developers] libxml2

[Erik Lindahl]

Hi,

On 18 Nov 2013, at 16:23, Mark Abraham <mark.j.abraham at gmail.com> wrote:

> Looks like a good start! Thanks.

Yes indeed!

> 
> I'm not sure whether <gromacs xmlns:gmx="http://www.gromacs.org/schemas"> should name a schema file, or a place to look up a schema file. Does anyone know? In the past I have seem XML files with namespace-specific content like

Formally it does not have to point to anything, IIRC; the only requirement is that it is a UUID (universal unique identifier) for each individual schema (thus, no common web page). However, I think it makes a lot of sense to make it point to an actual schema file, but since this is likely to be a quick/transient/temporary solution I also think it’s a good idea to create a special namespace (and schema) for it, rather than using the default “gromacs” name (since that will clobber all future usage)?

> 
>   <gmx:sfactors type="Fourier" force_field="any" displaced_solvent="true" reference="">
>     <gmx:sfactor residue="ALA" atom="MW" type="1”>

A couple of minor things:

* Since we’re moving to C++, should we use camelcase for new files? I also think we should write out names for clarity - in particular when we only use them a handful of times. In other words, I prefer “StructureFactor” over sfactor, etc. Readability rocks :-)

* When it comes to the type of structure factor, to me it looks as if this is specific to electronic structure factors (or will it work for neutrons or other stuff too?). In that case we should probably encode that!

* Units are great, although I would use “^-1” to denote each reciprocal component. That way we might have a chance of creating an automatic parsing in the future.

* Rather than doing “type=1”, what does the type mean here? It seems to be a different sort of “type” from the same field on the preceding line.

* To me it sounds _very_ bold to claim that a file will work for “any” force field. Will it really be applicable both to all-atom, united-atom and CG force fields of all kinds? If not, I think it should be FF-specific (just like we have copies of many other files in lots of directories)

* Not sure if this is complicated, but would it be possible to encode the order of each factor through an attribute rather than introducing new XML tags for each of them?

* Finally, to try and help rather than nitpicking about specific fields: David, perhaps you do a high-level description about the things you want to encode, and what choices we need for that? What choices are allowed in different parts?


Cheers,

Erik




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20131118/56ee6b11/attachment.html>