EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: V4 database definition files
From: "Rees, NP \(Nick\)" <[email protected]>
To: <[email protected]>
Date: Thu, 27 Oct 2005 14:47:43 +0100
This message is probably largely aimed at Andrew, but I thought I would
send it to core talk because it might provoke (hopefully useful)
discussion. It has grown out of trying to see where VDCT should evolve
on the V4/EPICS Office timescale. I must admit it started being a short
message about where Andrew see the "info" record item going, and grew
from there....

Anyway, I spent a lot of time at the recent meetings talking about
meta-data - which in my context means any information generated by the
developer(s) which is associated with the database definition, but is
not needed by the IOC. This is not a precise definition, but I don't
want to get to tied down in pedantry. Suffice to say I will illustrate
it with examples of what we need to do when defining a database, but
which is not used by the IOC:

1. Graphical information e.g.
    - position of a record on a graphical canvas (i.e. record metadata).
    - routing of links on a graphical canvas (i.e. link metadata).
    - border and textual information explaining a template (i.e. db or
dbd file meta data).
2. Archive information
    - which fields of a record to archive, at what rate etc (i.e. record
or field metadata) 
      to what archives or archive groups.
3. Alarm information
    - which alarm group a record belongs to, what that should happen
when elements in 
      that group go into alarm (record or field metadata).
4. Higher level device models:
    - explanation that this template represents the high-level concept
of a Monochrometer
      (or BPM), and that the Mono energy setpoint is found at this
particular record in 
      the template (template metadata)
5. Persistence information
    - is this record or field to be backed up to a permanent data store
and re-initialised 
      on reboot.
6. Equipment information
    - Explanation that this record is associated with this physical bit
of plant which 
      then links in with a relational database description of its
history.
7. Security information
    - Which security group this field belongs to. Who can change this
field.
8. GUI/client information
    - What units the data is, what is the high and low operating range,
update rates, 
      filters etc.

I am sure this list is not exhaustive, but it illustrates a point. There
is a lot more to database definition than what exists on the IOC. There
is also some aspects of database definition at the moment that is served
by the IOC but arguably doesn't have to be. You all know this. However,
I think for EPICS to hang together as a package then we need a way for
developers to generate all this data in a consistent way. This is
particularly important to me as the person in charge of VDCT. In this
role what I represent is the EPICS developer and I see that VDCT (or its
descendents) needs to grow to support these other areas, and we need an
ASCII file format that can grow with it. This is despite the fact that
much of this information may reside permanently in a database in a given
implementation - files are just useful things because they can be
version controlled, can be viewed as serialised objects, can be emailed
back and forth and can be edited in you favorite editor, so we always
need a file format.

Anyway, you should be able to see where I am going - the standard file
format that has all the tools and everyone rightly or wrongly embraces
nowadays is XML. I have searched the core talk list in vain for the
three letters "XML" and it doesn't show up. With all the changes to the
V4 db file syntax, have we considered adopting XML?

The advantages I see are:

1. The conversion between the V3 .db and .dbd file format and XML is
trivial (The same cannot be said of the V4 format as it currently
exists).
2. Parsers exist for all languages and platforms.
3. Validation definition languages are available and so we can formally
define the file in a way that it can be automatically validated (at
least to a large degree). This removes the need for a lot of bespoke
validation.
4. Parsing, validation and user code operations are kept separate. This
is really important because it introduces the concept that user code
ignores any structure it is not interested and so avoids the problem I
have of user code choking on any metadata which isn't an unstructured
comment. Application developers can the define metadata formats in the
knowledge they won't break other code. I would also assume that in our
case only the development tools would validate - the IOC's can use a
lightweight, not validating parser.
5. XSLT allows transformations between XML file types.
6. There are so many XML tools out there that some may even be useful.

Anyway, the advantages of XML are so great that I feel there is even a
case for VDCT to adopt its own XML format even if EPICS core doesn't -
and then generate a db file via a simple translator. This would mean we
would not have to change the parser every time the EPICS file format
changed. However, I feel it would be better to define an XML db file
format that is extensible and use it for everything.

What do people think? If it has already been discussed ad nauseum, can
someone point me to where I can find the pros and cons?

Cheers,

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


Replies:
Re: V4 database definition files Kay-Uwe Kasemir

Navigate by Date:
Prev: RE: Release 3.14.8: What goes in it and when? Jeff Hill
Next: Re: V4 database definition files Kay-Uwe Kasemir
Index: 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: CA V4 Protocol Specification Benjamin Franksen
Next: Re: V4 database definition files Kay-Uwe Kasemir
Index: 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·