Experimental Physics and
Industrial Control System

"Rees, NP \(Nick\)" <[email protected]> · Tue, 1 Nov 2005 11:30:20 -0000

Andrew,

Sorry for the delay in replying. We are caught up in a release at the
moment. However, to address your points:

> Your use of an attribute for the field value doesn't permit a 
> field to be a structure containing sub-fields, which themselves may be

> structures.

There are a number of ways around this, and you made one suggestion.
Alternatively, the value attribute is only valid for primitive fields,
but fields can have sub-elements. Alternatively, fields are leaf
elements, and we have a different name for node elements (e.g. struct,
like in the XML snippet you gave as your example at the end of your
message). I don't believe any of this is insurmountable.

> What are the requirements that we're not meeting right now? I'm happy 
> to discuss and change the info definition to make it more useful, if
you 
> let me know what you want to be able to do with it.

As Benjamin said, I think I listed about 10 different points and he
added numerical RDB keys. If you want me to define what I want instead
of the info definition, let me take a stab.

  - It needs to allow an arbitrarily structured hierarchies of metadata.
  - It needs a well defined ASCII syntax (so any client can parse it to
recognize its beginning and end) but make no un-necessary restrictions
on content.
  - It should be able to be validated generically but is ignored by
systems that don't recognize the relevant tags.
  - It needs to be able to be present anywhere in the file hierarchy,
since its scope will be defined by its position in the file.
  - If possible, tie-ins to existing tools with multi-language support
would be useful.

I could go on, but if you think about it, it sounds remarkably like XML.

> At APS we probably have at least 6 different ways in which DB 
> files get generated, using VDCT, GDCT, JDCT, Perl scripts, shell 
> scripts and hand editing.  The latter is still very common, and not
just among 
> the main core developers.  I expect developers to want to carry on
using their 
> favorite tools to generate application databases, and other people's 
> experience (not just Kay's) has shown that XML is not a good 
> choice for files that humans have to create by hand or read.

To be frank, I think this is because the development tools we provide
are sub-standard. At JAC we used Capfast, and occasionally hand-edited
the Capfast .sch files by hand if we wanted to do specific things. This
is despite the fact that Capfast isn't a particularly great tool. If we
used XML, and migrated VDCT to Eclipse as part of a graphics re-write,
we could easily integrate one of the various Eclipse XML editors into
the product as another view, and still have a standard text editor as a
basic view. I think this could all hang together quite nicely.

OTOH, I accept your point about writing parameters to command line
tools, but the question is whether the underlying format should be XML
or not. I could see us developing XML as the primary standard for data
interchange, but the IOC or the command line tools could have their own
private language and there be a well defined two-way mapping. Similarly
with the relational database and other tools. Good converters are really
useful pieces of software, but the mapping has to be well defined. But
we need a common language all the tools can communicate with.

Cheers,

Nick Rees
Principal Software Engineer           Phone: +44 (0)1235-778430
Diamond Light Source                  Fax:   +44 (0)1235-446713

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System